[RFC|Merged] Switch to PHP timezone handling

[ecvej]

How about:

1) Determine the users current GMT offset and display only those PHP timezones that have the same offset to narrow the choice to the most likely ones they will want to choose from.

2) Show a link to "select other timezone" if they want to pick a different timezone, which will show a GUI along the lines of what others have posted above.

[Dicky]

I would implement it with the 400-long alphabetical list of the timezones, at least for now.

I agree with doing it this way. A message board I know of has a dropdown list of 368 DateTimezones with user-friendly descriptions sorted alphabetically on these descriptions by country and then by region or state. It appears they also preselect a possible timezone according to your computer's timezone/offset. I don't find it difficult at all to locate and select a timezone from this list of 368 timezones. I don't believe it would be a problem for the average user either.

php.net has 454 DateTimezones (not including legacy timezones) listed on their website yet there are only 403 in the Identifierlist
wikipedia has 405 database timezones.

[EXreaction]

How about having two drop downs, one with the list of timezones, and another where you can select a +- hr and it would filter the main list of timezones to show only those with some JS?

[Oleg]

Possible source of inspiration:

http://edoceo.com/exemplar/php-timezone

[Oleg]

Something I discovered just now is that postgres prior to 8.0 (that is 7.3 and 7.4) does not support altering a column type in place.

The patch linked here does not appear to tackle schema upgrading at all, but migrations I implemented for my own version failed on 7.3.

A workaround would be to create a column with the desired type, copy data to it, then drop the old column. After that a vacuum is suggested by postgres to reclaim disk space.

References:

http://www.postgresql.org/docs/7.3/stat ... table.html
http://www.postgresql.org/docs/7.4/stat ... table.html
http://www.postgresql.org/docs/8.0/stat ... table.html

[naderman]

We need to come up with a clear guideline on using or not using @return void. If we had documentation on all functions it would be implicit. Technically a function returns null I believe and not void if there is no explicit return value. Not entirely sure what to do about this.

[bantu]

We need to come up with a clear guideline on using or not using @return void.

Yes, that makes sense.

Technically a function returns null I believe and not void if there is no explicit return value.

Correct. http://php.net/manual/en/functions.returning-values.php

[Oleg]

Rebased on top of develop. fixed one conflict with http://tracker.phpbb.com/browse/PHPBB3-7369 (which does not currently load): https://github.com/p/phpbb3/compare/dev ... z-handling

[Oleg]

Looks like I will be picking this up, and I decided to start on the timezone selector. I want to sort the list by timezone and provide timezone offsets next to names, which should make it fairly usable.

I plan on migrating existing users to GMT+-X timezones that I think are provided. That essentially carries over the pre-3.1 timezone behavior. Furthermore, I want to add those timezones (just the one the user is in) to the selector for existing users such that users are not required to change their timezone after board upgrade, and changing something else in board preferences does not change their timezone.

For new registrations I want to have the timezone offset detected via javascript to pre-select a timezone close to what the user would hopefully want.

The other big chunk that is missing is update code.

[nickvergessen]

Looks like I will be picking this up, and I decided to start on the timezone selector. I want to sort the list by timezone and provide timezone offsets next to names, which should make it fairly usable.

Well could you describe the way, you want to do that?
because like chris mentioned here we can not put the ~500 timezones in one dropdown?!