Time Zone Selector

[live627]

Another option is to use an automated time offset detector

[Arantor]

Another option is to use an automated time offset detector

There's one of those in the profile area, but it rounds to the nearest hour - there are two or three timezones that don't use that, however.

[MrPhil]

Another option is to use an automated time offset detector

Not really that good. The current code does this, but ends up with a fixed offset as a timezone "name" of Etc/GMT+5 and the like. I'm not sure it does DST at all, or if it still uses the server's local DST setting. At any rate, there are often complaints of it being "off". Also, this name format is not guaranteed to be around for any specific period of time!

What would be far better would be to allow the forum administrator (and individual members) to select the actual timezone name that PHP wants. Other supplementary timezone names can be offered for people too dumb to know what timezone they're in (EST-5EDT etc for US Eastern Time), which don't necessarily have the correct DST/Summer Time rules. Say, someone in Tucson, AZ picks Mountain Time, forgetting that Arizona doesn't observe DST. Unfortunately, you don't have the current list available before PHP 5.2, so some sort of backup method is needed -- a fixed list, a snapshot of the official PHP list, or something else. And then, valid timezone names may change over time (there are a whole bunch that are not guaranteed to survive for long). SMF could certainly preserve them in a list, mapping them to currently valid names. It could also distribute snapshots of the full list for users on 5.1.x systems.

If a timezone name becomes invalid, it will be rejected by date_default_timezone_set(). This needs to be detected and handled. One choice might be to demand that the admin or member immediately enter a new choice. Another would be to store the offset in hours from UTC/GMT or the server (when the old name was first selected) and use that as an emergency backup with the old hours offset code that SMF still uses. The system hour offset would be from the server time and the member offset would be added to that. If only one of the default and member choices has gone invalid, SMF might just use the other (still putting out a warning). If the system default timezone goes bad, email the admin (once per day), and use the member timezone if defined. If it's a guest or a member without a timezone selection, use the backup hour offset, and display a warning for the user. If a member's chosen timezone name goes bad, just use the system default with a warning to the member that they need to go into their profile and select a new timezone. If both system default and member timezone names are bad (!!), fall back to the hour offsets used by SMF on pre PHP 5.1 systems. I don't know if you'll get the PHP warning about no timezone selected, or what you could do about it.

The whole point is to not only get the correct offset from UTC/GMT (which may be fractional), but also to get the correct DST/Summer Time rules applied. That's just not something that can be done in an automated manner, as far as I can see -- whoever/whatever picks the timezone has to know which rules to apply, which means knowing which country (or part of a country) the forum or member is in. PHP has all this neatly wrapped up in the 5.1+ functions, so why not use them? It does mean that a human needs to pick the timezone from a list. Perhaps, as a backup if the forum administrator refuses to select the timezone, some sort of automated offset picker can be used, but it's bound to have the wrong DST/Summer Time rules if the server runs under different rules than the forum admin or member wants.

I will concede that the system that PHP selected, Continent/Major_City, leaves something to be desired. Some people will pick the nearest city on the list, rather than the one in their timezone. When presenting the timezone list, I think it will have to be enhanced with more information, such as
  America/New_York   Eastern US with DST  GMT-5/-4
  America/Phoenix  Mountain Standard US without DST  GMT-7
etc., plus lists of more familiar designations
  US Eastern Time with DST (ESTEDT)  GMT-5/-4
  US Mountain Standard without DST (MST)  GMT-7

You don't want to give only an offset from UTC/GMT, unless there is no DST/Summer Time observed or you're willing to follow whatever rule the server happens to use (which probably means just using the old hour offsets code, and finding a way to silence the PHP warning).

[Arantor]

This all assumes the server is configured in a sensible way, though. My VPS is in Dallas, which last I checked is in a region that handles DST - except the server's clock never changes for DST and I never reconfigure it (couldn't be bothered to figure it out to be honest)

[MrPhil]

Well, the idea is that as long as the server knows the correct UTC/GMT time is, it can present your correct local time (given the correct timezone name). It doesn't matter how strangely the server's timezone is configured, so long as the basic clock is correct. No fooling with system and member hour offsets, and no worrying about the server being on different DST rules than you want.

[青山 素子]

I will concede that the system that PHP selected, Continent/Major_City, leaves something to be desired. Some people will pick the nearest city on the list, rather than the one in their timezone. When presenting the timezone list, I think it will have to be enhanced with more information, such as
  America/New_York   Eastern US with DST  GMT-5/-4
  America/Phoenix  Mountain Standard US without DST  GMT-7
etc., plus lists of more familiar designations
  US Eastern Time with DST (ESTEDT)  GMT-5/-4
  US Mountain Standard without DST (MST)  GMT-7

The PHP timezone list is pulled using the very standard tz database. It's used by nearly all Linux and UNIX systems, is used by Java, and supposedly even by OS X.

For the most part, the nearest city will be in the same timezone, escept in very rare circumstances with cities on the border of a zone. It's not too difficult to modify the instructions to "pick the nearest city in the same timezone".

You don't want to give only an offset from UTC/GMT, unless there is no DST/Summer Time observed or you're willing to follow whatever rule the server happens to use (which probably means just using the old hour offsets code, and finding a way to silence the PHP warning).

Agreed that it is a bad way to manage things.

This all assumes the server is configured in a sensible way, though. My VPS is in Dallas, which last I checked is in a region that handles DST - except the server's clock never changes for DST and I never reconfigure it (couldn't be bothered to figure it out to be honest)

It is very possible that the timezone is configured wrong, or it was set up with an offset number rather than the city. If you want to see the timezone file you are using, on a Linux system, run "strings /etc/localtime". The last line should show the internal name. For instance, my system here is using "PST8PDT".

On a Redhat or derived system, you can look at the contents of "/etc/sysconfig/clock" to see the friendly-name timezone file that is being used. To update, copy one of the files under /usr/share/zoneinfo (for me, it would be /usr/share/zoneinfo/America/Los_Angeles) to /etc/localtime. This will have the immediate effect of changing the displayed time to that zone (Linux uses UTC internally, so it doesn't need to make adjustments). You should also edit /etc/sysconfig/clock for consistency (some of the system tools use it).

Note that if you are using a zone like UTC and you set the clock to match local time, it will look to be incorrect once you make that change. Use "ntpdate pool.ntp.org" to set the correct time.

[klumy]

the current time selector is a little bit uncomfortable for the user. Maybe it would be good, if during selection, SMF would also show some example cities like New York etc. instead of inly hours

[青山 素子]

the current time selector is a little bit uncomfortable for the user. Maybe it would be good, if during selection, SMF would also show some example cities like New York etc. instead of inly hours

SMF doesn't handle timezones at all, so it can't determine that information.

[MrPhil]

I will concede that the system that PHP selected, Continent/Major_City, leaves something to be desired. Some people will pick the nearest city on the list, rather than the one in their timezone.

The PHP timezone list is pulled using the very standard tz database. It's used by nearly all Linux and UNIX systems, is used by Java, and supposedly even by OS X.

Well, it's quite usable by geeks and people with high IQs. For most people, unless you give very explicit instructions, they're not going to be able to use it correctly. I still say it's poorly designed, for that very reason. There's no rhyme or reason to the list of cities offered -- it would be much better to offer (instead, or in addition) a timezone name and country (USA -- Eastern Time, or USA -- Mountain Standard Time [Arizona], etc.). Give people all the help you can -- they need it.

This all assumes the server is configured in a sensible way, though. My VPS is in Dallas, which last I checked is in a region that handles DST - except the server's clock never changes for DST and I never reconfigure it (couldn't be bothered to figure it out to be honest)

It is very possible that the timezone is configured wrong, or it was set up with an offset number rather than the city. If you want to see the timezone file you are using, on a Linux system, run "strings /etc/localtime". The last line should show the internal name. For instance, my system here is using "PST8PDT".

Servers are often set up to show GMT or some offset from it, rather than the true local time (including DST). Don't bother trying to fight it -- use the PHP timezone functions.

the current time selector is a little bit uncomfortable for the user. Maybe it would be good, if during selection, SMF would also show some example cities like New York etc. instead of inly hours

SMF doesn't handle timezones at all, so it can't determine that information.

SMF does handle timezones, if you install into a system that is already at PHP 5.1 or higher. It will use the date_default_timezone_set() call and you just leave your system offset at 0 hours. During installation, it sets (in smf_settings table) "default_timezone" to what it thinks is the correct timezone. Unfortunately, it's wrong ("Etc/GMT+5" instead of "America/New_York") so you don't get your timezone's DST rules. It's easy enough to go into phpMyAdmin and correct your timezone (or add it, if your original install was on a pre PHP 5.1 system). This will give you the correct PHP timezone for the system. Unfortunately, inidividual members are still stuck with the hours offset, which means they use the forum's (guest's) DST rules. It would take a mod to add/change a field in member data to have the timezone name per member, and a way for a member to select their timezone. Maybe keep the old member hour offset to use as a backup when they haven't selected a timezone, or for some reason have an invalid timezone name. It doesn't matter if SMF applies the default (forum) timezone first, and then the member's is applied, or just do the member's only.

[Tanith0709]

Not sure if its been mentioned before. But about the time zone, I'm wondering: Why can't the user select the timezone they're in or at least have the ability to "Offset" their time during the registration process?

To me that's one feature I would expect to see in any forum software as it's more user friendly. Not everyone would assume that they can change it via their profile and thus complain to the admin(s) of the site.

[MrPhil]

That's what I've been suggesting, if you read the whole topic. System/Guest timezone should be selectable, as should Member timezone, using the same mechanism. There's a chance that any named timezone will become obsolete in time and need to be changed by the administrator or member, but that can be flagged for the appropriate person to deal with (the question becomes "what does SMF use for a fallback timezone until the named timezone is fixed?").

Time "offsets" are undesirable because you're adding/subtracting a fixed number of hours to the system time. The problem with this is that your member is then under the same DST/Summer Time rules as the server or its named timezone, which is not always correct. Say my server is in Arizona (Mountain Standard Time year-round) and I set up my system default +3 -- for most of the year the time is off by 1 hour. If I select America/New_York -- the System/Guest time is correct. Either way, a member with a +/- hour offset is going to be using US DST rules, even if they're in, say, Australia. That's not desirable.

[Vince S]

I have read lots of stuff here about this time zone thing - in the scheme of things it is a small banana, but it wears you down by bobbing up 4 times a year, for us anyway.

We've been using SiteGround with Texas based servers for a long time. All our users are based in east coast of Australia but obviously that could change for others. So there is "server time", "forum default timezone = offset" and "user time zone". These need three different tables to be running to get accuracy, anything else is a cop-out (on a small banana, so no whinging allowed).

What really happens is one sets the correct offset. Then the server goes to DST. Then the server goes off DST, then the local forum time goes to DST, then local goes off. Obviously users could be on their own off-set, and could easily be in a different DST zone themselves. Have a gander at them all http://www.timeanddate.com/library/abbreviations/timezones/na/edt.html. Also not all servers observe DST, but ours does.

So, some time after it happens I notice and adjust the off-set. A nuisance, but I have had more than a few q's about people thinking the stated post time is the real time. The other complication one gets is that the offset is the time at the moment and all posts are displayed in that offset regardless of what the offset was at the time of posting. To fix this silly, small banana thing up someone would have to a) care enough to bother, and b) be prepared to add a time zone variable to posts, add server zone & forum zone variables AND add lookup tables to track all the world's time zones, with some form of maintenance when the various political forces cause them to change - probably this latter is version release frequency as the world has largely come to grips with the topic and stabilised, mostly. A separate element from earlier posts is that the way users figure out which zone they are in could also be easier - this may not matter so much IMHO if, once they picked a time zone, it stayed fixed!

If the above happened we would have automated time zone adjustments that worked, anything less and we may as well not bother. Does the high read count of this topic say it is worth sticking on the "to do" list? It is certainly a piece that adds a very amateurish albatross around the neck of an otherwise excellent piece of community / hard working individuals' work. Please remember that, by definition, this is NOT a whinge! But wouldn't it be cool if it could be done?

[Tanith0709]

Out of curiosity has any progress been made related to this?

Is it possible to just implement a user selection option like this which is a lot more user friendly?

[MrPhil]

It could be done by expanding the system offset and member offset fields to something large enough to hold the longest text timezone name. For pre-5.1.0 systems, it would have to hold (as text) an hour offset, as is done today. For 5.1.0+ systems, it would hold timezone names or hour offsets (preferably the former). The time-related code would have to recognize either a timezone name or a numeric hour offset, and run the appropriate code. At the top of a page, if there is a timezone name, call the appropriate function (I think that code has been in for a while, but only for system timezone). Provide a nice interface for selecting a timezone name -- PHP 5.2+ offers a list of available names (it's bizarre that 5.1 did not). Add "standard" names like "EST-5EDT" and map them to what PHP is expecting. Gracefully handle admins and users neglecting to select timezone names, or timezone names changing. Gracefully handle older PHP levels with numeric hour offsets, and upgrades to the new timezone names.

This would be a fairly big mod, but would bring SMF out of the stone age.

[青山 素子]

Gracefully handle admins and users neglecting to select timezone names, or timezone names changing. Gracefully handle older PHP levels with numeric hour offsets, and upgrades to the new timezone names.

Timezone names shouldn't change. As PHP uses the tz database data, the names are fairly standard. You could even break into two dropdowns, one for the item before the slash, and a dynamically-populated second based on the selection of the first. For example, I can select "America / Los Angeles".

This would be a fairly big mod, but would bring SMF out of the stone age.

Well, timezone handling with PHP hasn't been all that good until recently. I wouldn't put the full blame on SMF.