Make WordPress Core

Opened 18 years ago

Closed 16 years ago

Last modified 4 years ago

#3962 closed task (blessed) (fixed)

WordPress should adjust for DST ("location" appropriate)

Reported by: iacas's profile iacas Owned by:
Milestone: 2.8 Priority: high
Severity: normal Version: 2.1.2
Component: Date/Time Keywords: needs-testing
Focuses: Cc:

Description (last modified by lloydbudd)

WordPress should adjust for DST ("location" appropriate)

WordPress should be blog time "location" aware. "WordPress does not do daylight savings time (DST)"

WordPress respecting and adjusting to a blog's "location" is a regularly reported and frustrating issue. People forget about UTC offset as it is unfamilar in their other computing experiences.

Original report:

XML-RPC Incorrectly Handles New Daylight Savings Time

This problem is twofold, I believe. A little more information is here:
http://nslog.com/2007/03/12/wordpress_212_and_daylight_savings

Problem 1: Posting
When posting content via an XML-RPC client, WordPress subtracts one hour from the time. Running "date" on the command line or via PHP's "date()" function returns the correct time. Setting the time in the WordPress (wp-admin) web interface does not "subtract" an hour.

Problem 2: Viewing
Despite the server returning the correct time via "date" on the CLI or via PHP's "date()", articles set to publish at 10:00 will not appear until 11:00.

Attachments (11)

3962.diff (6.6 KB) - added by Otto42 16 years ago.
First draft of smarter timezone support
timezone-etc.diff (2.2 KB) - added by Otto42 16 years ago.
timezone-dstinfo.diff (3.5 KB) - added by Otto42 16 years ago.
Same as etc patch, with added DST info
tz-convert-fix.diff (668 bytes) - added by Otto42 16 years ago.
Fixes the sign problem when converting from gmt_offset to new Etc/GMT timezone
i18n-timezones.diff (1.4 KB) - added by nbachiyski 16 years ago.
timezone-wording.diff (2.1 KB) - added by nbachiyski 16 years ago.
tz-autocomplete.diff (36.3 KB) - added by sambauers 16 years ago.
tz-autocomplete-2.diff (39.6 KB) - added by sambauers 16 years ago.
tz-autocomplete-3.diff (39.6 KB) - added by sambauers 16 years ago.
Latest for trunk at [11238]
tz_filter.diff (453 bytes) - added by Otto42 16 years ago.
Adds a filter to wp_timezone_supported output
kubuntu-ubiquity-where-are-you.png (119.5 KB) - added by demetris 16 years ago.
Kubuntu, Ubiquity installer, Timezone selection, screenshot taken from the Kubuntu wiki: https://wiki.kubuntu.org/

Download all attachments as: .zip

Change History (136)

#1 follow-up: @westi
18 years ago

  • Keywords reporter-feeback added
  • Milestone 2.1.3 deleted
  • Priority changed from high to normal

WordPress does not do DST.

AFAIK any time related offset changes that WordPress makes are based on the time difference specified in the admin ui.

Please provide more information as to the specific setup and problem.

#2 in reply to: ↑ 1 ; follow-ups: @iacas
18 years ago

Replying to westi:

WordPress does not do DST.

WordPress should rely on the server for its date and time. We're living in the 21st century. Manually changing the time two times per year is so 1995.

#3 in reply to: ↑ 2 @Nazgul
18 years ago

WordPress should rely on the server for its date and time. We're living in the 21st century. Manually changing the time two times per year is so 1995.

My server is in the UK, I'm in Holland. I wouldn't be happy if the DST settings where managed by the server

#4 in reply to: ↑ 2 @westi
18 years ago

Replying to iacas:

Replying to westi:

WordPress does not do DST.

WordPress should rely on the server for its date and time. We're living in the 21st
century. Manually changing the time two times per year is so 1995.

Except that in many if not most cases the server and the end-user will be in different timezones - so relying on the server for time won't help.

#5 follow-up: @Otto42
18 years ago

Part of the problem is described by westi (the user needs the ability to be in a different timezone than the server) and part of the problem is that the timezone stuff in PHP versions earlier than PHP5 is quite weak.

It would be nice to abstract the timezone handling out into some functions so that we could include support for the date_default_timezone_set() stuff for PHP5 systems, and continue with the existing support for PHP4 systems. This would allow it to handle DST changes automatically (assuming the system itself supported it correctly). Timezones would need to be a string from a big list, like "America/Chicago" and so forth (full list here: http://php.net/manual/en/timezones.php ).

It might also be able to support this sort of thing for PHP4 by using the putenv('TZ=...') workaround.

#6 in reply to: ↑ 5 ; follow-ups: @iacas
18 years ago

Replying to Otto42:

Part of the problem is described by westi (the user needs the ability to be in a different timezone than the server) and part of the problem is that the timezone stuff in PHP versions earlier than PHP5 is quite weak.

Virtually every server I've seen in the past allows the user to set the time zone in which they reside. It's not universal, but it's rather common. How about an option to "use server time" or to specify your own UTC offset?

In PHP, "date()" works reliably if the user can set the time zone.

#7 in reply to: ↑ 6 ; follow-up: @westi
18 years ago

Replying to iacas:

Replying to Otto42:

Part of the problem is described by westi (the user needs the ability to be in a different timezone than the server) and part of the problem is that the timezone stuff in PHP versions earlier than PHP5 is quite weak.

Virtually every server I've seen in the past allows the user to set the time zone in which they reside. It's not universal, but it's rather common. How about an option to "use server time" or to specify your own UTC offset?

Yes, the server will have a timezone set on it. But most servers on which WordPress is installed support multiple Users who are quite conceivably in different timezones.

#8 in reply to: ↑ 6 @Otto42
18 years ago

Replying to iacas:

Virtually every server I've seen in the past allows the user to set the time zone in which they reside. It's not universal, but it's rather common. How about an option to "use server time" or to specify your own UTC offset?

In PHP, "date()" works reliably if the user can set the time zone.

That's sort of the problem. We do have the ability for a user to set their own offset from UTC, in a number of hours (-6, for example). What we *need* is a more standard timezone handling mechanism.

Generally, you don't set your timezone as a UTC offset. You set it as a location. Like America/Chicago, or Europe/Amsterdam or what have you. This not only sets your offset, but regional variations as well.

In PHP4, this was all based off the contents of the TZ environment variable.
In PHP5, they added functions to set it more directly, like date_default_timezone_set().

In either case, date() will reliably give the correct local time for any given timezone *if* one of those are set properly. Wordpress is doing neither. It's just multiplying the offset by 3600 and adding it to the time output wherever it needs a date. All these can be eliminated with proper timezone handling.

#9 in reply to: ↑ 7 @Otto42
18 years ago

Replying to westi:

Yes, the server will have a timezone set on it. But most servers on which WordPress is installed support multiple Users who are quite conceivably in different timezones.

That's another problem. Wordpress can have more than one User, but it cannot have more than one time offset. This could be handled as well.

Note that this could conceivably be done with a plugin as well. By setting the built in offset to zero, you can then use the right methods to do it. Tell you what, I'll work out a quick example sometime next week and post it up for everybody to look at, and try on their systems. Because of the version differences, we'd probably want to test it on several platforms/servers/PHP versions.

#10 @ryan
18 years ago

Now that contemporary versions of PHP ship with a version of the Olson database via timezonedb, proper DST support is more attainable. It's still a pain in the ass to get it right and a fairly pointless endeavor for php4.

http://laughingmeme.org/2007/02/27/looking-at-php5s-datetime-and-datetimezone/
http://www.torenware.com/handbooks/timezones
http://drupal.org/node/11077

#11 @molecularbear
18 years ago

I have been experiencing "Problem 2: Viewing" that the original poster describes (all dates appear correct, server time is correct, I have adjusted the UTC offset in WP, etc). I found that newly published posts in the database had the correct post_date, but that the post_date_gmt was off by one hour. I tracked the problem to function get_gmt_from_date in formatting.php, but found that the issue ran deeper than the WP code.

Function gmmktime depends upon function mktime. I am running PHP 4.3.4, but according to the PHP ChangeLog, there was a bug in mktime that was fixed in PHP 4.3.6.

To see if you have the same problem, check your PHP version with php -v, or run this:

echo gmdate('Y-m-d H:i:s', gmmktime(0, 0, 0, 4, 20, 2007)) . "\n";

The correct output is this:

2007-04-20 00:00:00

The problematic output is this (i.e., an hour off):

2007-04-20 01:00:00

#12 @Nazgul
17 years ago

  • Milestone set to 2.4 (future)

#13 @thee17
17 years ago

  • Summary changed from XML-RPC Incorrectly Handles New Daylight Savings Time to XML-RPC Incorrectly Handles New Daylight Savings Time hunt-irrelivent

I think this problem should not be fixed

#14 @thee17
17 years ago

  • Keywords hunt-irrelivent added
  • Summary changed from XML-RPC Incorrectly Handles New Daylight Savings Time hunt-irrelivent to XML-RPC Incorrectly Handles New Daylight Savings Time

#15 @darkdragon
17 years ago

  • Keywords hunt-irrelevant added; hunt-irrelivent removed

#16 @josephscott
17 years ago

  • Cc josephscott added

#17 @thee17
17 years ago

  • Keywords hunt-irrelevant removed
  • Resolution set to invalid
  • Status changed from new to closed

#18 @lloydbudd
17 years ago

  • Keywords reporter-feeback removed
  • Milestone changed from 2.4 to 2.6
  • Resolution invalid deleted
  • Status changed from closed to reopened

#19 @lloydbudd
17 years ago

  • Component changed from XML-RPC to General
  • Description modified (diff)
  • Summary changed from XML-RPC Incorrectly Handles New Daylight Savings Time to WordPress should be blog time "location" aware

Re-opening and setting for consideration in a future release (PHP5?)

The more basic issue of WordPress respecting and adjusting to a blog's "location" is a regularly reported and frustrating issue. People forget about UTC offset as it is unfamilar in their other computing experiences.

#20 @lloydbudd
17 years ago

  • Description modified (diff)
  • Summary changed from WordPress should be blog time "location" aware to WordPress should adjust for DST ("location" appropriate)

#21 follow-up: @caesarsgrunt
16 years ago

  • Type changed from defect to enhancement

+1. Can Otto's plugin be integrated easily? (I haven't really looked at this, but it would be very nice if this feature were a part of the core...)

#22 in reply to: ↑ 21 @Otto42
16 years ago

Replying to caesarsgrunt:

Can Otto's plugin be integrated easily?

Yes, it can, I just haven't had the time to sit down and make the necessary patch to do it. When the new UI stabilizes a bit more, I'll add it in.

#23 @matt
16 years ago

  • Milestone changed from 2.7 to 2.8

#24 @westi
16 years ago

  • Cc westi added
  • Component changed from General to Administration
  • Priority changed from normal to high

What I would like to see for 2.8

Timezone selection based on Ottos plugin but with a guided selection going through at least Contient first to reduce the list.

Maybe we could get Translated installs to set a better default as well

#25 @janeforshort
16 years ago

  • Milestone changed from 2.8 to 2.9

Moving to 2.9 due to time unless someone want to do the development for this. Move to 2.8 only if you have attached a patch. Thanks!

#26 @murky
16 years ago

This is fixed in a plugin
http://ottodestruct.com/blog/wordpress-plugins/automatic-timezone/

Though, I agree this would be infinitely better as part of the core.

#27 @Otto42
16 years ago

Still working on it. I hope to have a patch before 2.8.

#28 @ryan
16 years ago

  • Milestone changed from 2.9 to 2.8
  • Type changed from enhancement to task (blessed)

I'm going to be optimistic and milestone this for 2.8. :-)

#29 @Otto42
16 years ago

  • Keywords needs-testing added

Okay, uploaded a first draft patch. This is a simple patch, not the best UI in the world, but it works. Needs more refinement and testing before I'd say it's ready.

@Otto42
16 years ago

First draft of smarter timezone support

#30 @Otto42
16 years ago

Anybody tried this yet? Any feedback? Any thoughts on the interface?

It's been mentioned that the single dropdown kinda sucks for an interface, so I was thinking of a jquery based multiple dropdown, where you first select the continent, then select the relevant timezone, but that seems kind iffy to me, and I can't think of a better way to do it.

#31 follow-up: @westi
16 years ago

Good Work!

I think a set of dropdowns which are javascript loaded would be good.

Maybe browser js support is another requirement as well as PHP5 for the improved interface.

I guess we also need a way of getting from the current option to a good guest for the new one - can this be done easily other wise people may trash there timezone accidentally.

#32 in reply to: ↑ 31 @Otto42
16 years ago

Replying to westi:

I guess we also need a way of getting from the current option to a good guest for the new one - can this be done easily other wise people may trash there timezone accidentally.

Well, right now, the code that generates the dropdown is intentionally ignoring non-location based timezones, although they are usually available. For example, in my local installation, PHP returns a list of zones named like "Etc/GMT-6". If these are there, it would not be a huge stretch to have it default to one of these if no location-aware TZ is selected.

I could also make it display the DST rule for the selected timezone. My plugin does this if it detects support for it. It says something similar to "This timezone is currently in standard time. This timezone switches to daylight savings time on: March 8, 2009 @ 3:00 am CDT" and so forth. Bit of feedback to let you know if the location you picked is correct.

#33 @ryan
16 years ago

Both of those suggestions sound good.

#34 @sambauers
16 years ago

Please keep UTC as a timezone option in the dropdown.

#35 @sambauers
16 years ago

The current offset (which will still be set after upgrade) is not shown anywhere if these functions and dropdown is available. It would be good to have there as a reference if it is set.

I like the optgroup approach, I don't think fancy js is required for a set and forget option like this.

#36 @ryan
16 years ago

(In [10753]) Timezone support. Props Otto42. see #3962

#37 follow-ups: @ryan
16 years ago

Filtering by continent excluded quite a few countries in my environment, so I changed it to display everything returned by timezone_identifiers_list(), grouped by continent where there is one.

#38 in reply to: ↑ 37 @sambauers
16 years ago

Replying to ryan:

Filtering by continent excluded quite a few countries in my environment, so I changed it to display everything returned by timezone_identifiers_list(), grouped by continent where there is one.

All the timezones on this page (see warning on that page):

http://www.php.net/manual/en/timezones.others.php

Are deprecated and should not be used (except UTC). All of them should have a sensible equivalent in the filtered set of timezones in the original patch.

#39 @Otto42
16 years ago

I didn't quite mean for the patch to be moved in yet, but that's okay. I'll provide another patch tomorrow to finish up the timezone support. I've got it half done, still working on the Etc bits.

As far as the "deprecated" ones goes, I'm not planning on filtering them out unless I can find a way to have PHP itself tell me whether they're deprecated. The patch gets the list direct from timezone_identifiers_list(), which I think does not filter those. There may be a way to detect obsolete timezones, but I haven't found it yet.

The problem is that I want PHP itself to do the heavy lifting and tell me what timezones are valid vs. what are not. Since it has the timezonedb in it, that info should be there, I just haven't worked it out yet. Something in the transitions list eludes me.

#40 @Otto42
16 years ago

Oh, also, that deprecated list includes the Etc/GMT ones, which we definitely do NOT want to exclude, despite what that page says. We need to keep the option to manually select the offset directly, as discussed before, and that's exactly what those do.

#41 in reply to: ↑ 37 @Otto42
16 years ago

Replying to ryan:

Filtering by continent excluded quite a few countries in my environment, so I changed it to display everything returned by timezone_identifiers_list(), grouped by continent where there is one.

Anything in particular that was excluded? I just tested trunk and it has a lot of things that I think probably should not be in there. I filtered by continent to exclude those, and though I'm working on a better exclusion method, I'm not sure it will give what you're looking for.

Timezonedb stores zones by city names, not by country. So even if a country is "missing", that's probably because it has the same rules as a city in some other country.

#42 @sambauers
16 years ago

If you use DateTimeZone::listIdentifiers() which is it's OOP parent on php >= 5.3.0 then you can filter out by groups according to these constants http://www.php.net/manual/en/class.datetimezone.php But that doesn't do exactly what you want anyway.

Other than that, your manual approach is the only way I think. I'm not sure it's such a big performance problem anyway.

If you want to save on execution time then you should probably filter out the zones you don't want on the first foreach loop in wp_timezone_choice() and filter using in_array() instead of the series of conditionals in your original patch.

Filtering in the first loop will save a little memory (no point in storing things you won't use) and in_array() will be faster as it pulls all those conditions into compiled code (probably more friendly to php accelerators too).

#43 @ryan
16 years ago

(In [10755]) Exclude deprecated timezones. see #3962

#44 @ryan
16 years ago

(In [10756]) Filter continents in the first loop. see #3962

#45 @ryan
16 years ago

Put the list back in. I'll stop there before I mess things up any more. :-)

#46 @Otto42
16 years ago

Added a patch to fix the selected parameter in the choice dropdown (having an extra space in that bit in Firefox mucked it up for some reason), and to add smart handling of the older selection method. If no timezone string is found, it'll use the existing gmt_offset to build an "Etc/GMT+5" or similar string, and pre-select that in the selection box.

@Otto42
16 years ago

@Otto42
16 years ago

Same as etc patch, with added DST info

#47 @Otto42
16 years ago

Here's a second patch, which adds the same stuff as the etc patch, along with the ability to display more information about the Daylight Savings rules of the selected timezone. I'm not sure exactly how best to display this information to the user though.

It displays two things:
a) Whether the selected timezone is currently in daylight savings or standard time.
b) When the switchover to the other will occur (in that local time), or if the timezone does not do daylight savings at all.

Suggestions on how to display this info better would be appreciated.

Note that the patch only adds this information if the timezone_transitions_get() function exists, which means only PHP 5.2 and up will show the info. Older PHP's will show nothing.

#48 @nbachiyski
16 years ago

  • Cc nbachiyski@… added

#49 @ryan
16 years ago

(In [10757]) Show DST info. Map old offest to Etc zones. Props Otto42. see #3962

#50 @Otto42
16 years ago

Just discovered a problem. Strangely, PHP has the plus/minus reversed on the Etc/GMT timezones. I'm currently sitting in the GMT-6 timezone as described by this map: http://www.worldtimezone.com/ , but to get it to show the right time, I have to select GMT+6 (well, +5 actually, since I'm in DST right now). The point is that the + and minus are reversed.

I'm not sure how to handle this properly. I can easily reverse the sign correctly, but people might get confused if they want to select an Etc timezone.

Note that this problem is mentioned in the comments on http://www.php.net/manual/en/timezones.others.php and I've confirmed that it's occurring in this case as well.

@Otto42
16 years ago

Fixes the sign problem when converting from gmt_offset to new Etc/GMT timezone

#51 @Otto42
16 years ago

Argh. As it turns out, the sign reversal is not an error. From the Olson DB:

# We use POSIX-style signs in the Zone names and the output abbreviations,
# even though this is the opposite of what many people expect.
# POSIX has positive signs west of Greenwich, but many people expect
# positive signs east of Greenwich. For example, TZ=’Etc/GMT+4′ uses
# the abbreviation “GMT+4″ and corresponds to 4 hours behind UTC
# (i.e. west of Greenwich) even though many people would expect it to
# mean 4 hours ahead of UTC (i.e. east of Greenwich).

I could make the dropdown display correct these for display purposes only, so people don't pick the wrong things. Good idea? Bad idea?

#52 follow-up: @sambauers
16 years ago

This is why we should just leave them out altogether. If they already have a GMT+# timezone specified then show that in a note, not the dropdown.

#53 in reply to: ↑ 52 ; follow-up: @Otto42
16 years ago

Replying to sambauers:

This is why we should just leave them out altogether. If they already have a GMT+# timezone specified then show that in a note, not the dropdown.

Well, we still want them to be able to manually select a timezone directly, as some people won't want to pick a city.

Since the Etc ones are potentially confusing, I'm thinking of just adding a bunch of "UTC-10" ones directly in and then having them clear the timezone string entirely and set the gmt_offset directly, much like the old way. But they'd still be in the dropdown list.

I'll work up a patch for that, show you what I mean.

#54 @nbachiyski
16 years ago

A patch, which doesn't break a single phrase into several translatable strings. Please, don't do that.

#55 @ryan
16 years ago

(In [10770]) Use full strings for i18n friendliness. Props nbachiyski. see #3962

#56 in reply to: ↑ 53 @ryan
16 years ago

Replying to Otto42:

Replying to sambauers:

This is why we should just leave them out altogether. If they already have a GMT+# timezone specified then show that in a note, not the dropdown.

Well, we still want them to be able to manually select a timezone directly, as some people won't want to pick a city.

Since the Etc ones are potentially confusing, I'm thinking of just adding a bunch of "UTC-10" ones directly in and then having them clear the timezone string entirely and set the gmt_offset directly, much like the old way. But they'd still be in the dropdown list.

I'll work up a patch for that, show you what I mean.

That sounds good. Would UTC (no offset) map to Etc/UTC?

#57 @nbachiyski
16 years ago

A patch with light UI/wording changes:

  • The "Choose a city in the same timezone as you." label is moved right below the select box. It is supposed to describe the drop-down, but is too far from it if there are daylight-saving notifications.
  • References to the current timezone are implied. We don't need to say that the daylight savings time in the current timezonestarts on a certain date.
  • Added explanation what daylight savings time means (moving the clock)

#58 @ryan
16 years ago

"You will have to move your clock 1 hour forward." DST adjustment should be automatic now. Do we need this text?

#59 @nbachiyski
16 years ago

My bad. It should tell you in what direction the time changes, not to move your blog clock. I agree it is confusing this way.

"The clock moves 1 hour forward then."?

#60 @Viper007Bond
16 years ago

timezone-wording.diff also fixes a PHP notice related to $current_offset_name being undefined.

If the patch is changed to something different or not commited, then $current_offset_name needs to be replaced with htmlspecialchars($tzstring) or something.

#61 @ryan
16 years ago

(In [10878]) Improve timezone wording. Props nbachiyski. see #3962

#62 @ryan
16 years ago

Anything else to do here? Include UTC offsets as Otto42 proposed?

#63 @Otto42
16 years ago

The timezone reversal bug still exists. When upgrading from the old version to the new version, and it tries to auto-select the Etc timezone based on the existing gmt_offset, it will get it wrong. The patch I submitted before (tz-convert-fix.diff) still needs to be applied to correct this. Right now, it's a definite bug.

As for leaving the Etc timezones or switching to UTC timezones, that's up for discussion. I think that the reversed signs in the Etc zones is too confusing to leave them there. Quirk of the timezonedb, but it's still reversed from every other usage, and it will cause problems in the long run.

#64 @ryan
16 years ago

(In [10962]) Fix sign problem when converting from gmt_offset to new Etc/GMT timezone. Props Otto42. see #3962

#65 follow-up: @sambauers
16 years ago

I still think the numbered GMT offsets are absolutely not necessary and are confusing. Also, there aren't any 30 minute or 45 minute offsets as listed in the old timezone implementation.

There are too many similar options which are completely equivalent or antiquated. E.g.: UTC, UCT, Universal, GMT, GMT0, GMT+0, GMT-0 are all equivalent and the GMT options are antiquated.

In the Australia group about half of them are antiquated (and effectively duplicates) as they are regions rather than cities. A user setting their timezone in Sydney will have an unnecessary choice between Sydney and NSW. A user in Broken Hill will possibly be confused between Adelaide, South, Broken Hill, Yancowinna, Sydney and NSW.

Other continents contain multiple spellings or instances of the same location - Ulaanbaatar and Ulan Bator - Faroe and Faeroe - Argentina/Buenos Aires and Buenos Aires.

We may suffer a few complaints if we include the colonial name of the Indian city Calcutta as well as the modern Kolkata. Same applies if we have Saigon as well as Ho Chi Minh (Which should be "Thanh Po Ho Chi Minh").

Antarctica can just be left out completely. (Bases there usually set themselves to the same time as their supply station, which they would know without the aid of the individual listings).

A full separate 'Arctic' grouping for the sake of one island is excessive (they know they follow Norway time anyway).

Basically, we need a set of saner zones for this to not cause issues.

I suggest we create a lookup table (using an array in PHP) which maps a set of timezones which we specify to ZoneInfo names. This will (for example) more than halve the zones for Australia and we can deal with some of the problems here on a case by case basis.

It should be possible to get the community to contribute to sane sets of local timezones for there region/country.

#66 @sambauers
16 years ago

This library is quite nice (although not exhaustive) and might provide a nice jumping off point.

http://open.omnium.net.au/trac/browser/trunk/codebase/includes/libraries/locations.library.php

#67 in reply to: ↑ 65 ; follow-up: @Otto42
16 years ago

Replying to sambauers:

Basically, we need a set of saner zones for this to not cause issues.

We do not maintain the zone list, nor do I think we really want to. The zone list comes straight from PHP itself, which gets it from the zoneinfo database. Furthermore, what you see may not be the same as what anybody else sees, as different versions of PHP, different versions of the zoneinfo db, etc, etc.

It should be possible to get the community to contribute to sane sets of local timezones for there region/country.

Unnecessary duplicate work. All this is done for us by the zoneinfo maintainers and the PHP developers who include the db in the system.

#68 in reply to: ↑ 67 ; follow-up: @sambauers
16 years ago

Replying to Otto42:

Replying to sambauers:

Basically, we need a set of saner zones for this to not cause issues.

We do not maintain the zone list, nor do I think we really want to. The zone list comes straight from PHP itself, which gets it from the zoneinfo database. Furthermore, what you see may not be the same as what anybody else sees, as different versions of PHP, different versions of the zoneinfo db, etc, etc.

Regardless of the origin of the list (and perhaps because of the slightly unpredictable set of zones that it may contain) we need to provide a set of zones that are tailored towards greater usability, which the PHP zones are not. For a good example of a usability layer in front of the ZoneInfo DB see the Mac OS X timezone selection UI. I'm not advocating that we need a full map, just a more sensible list of cities to choose from, without duplicates and legacy names.

It should be possible to get the community to contribute to sane sets of local timezones for there region/country.

Unnecessary duplicate work. All this is done for us by the zoneinfo maintainers and the PHP developers who include the db in the system.

I feel it is necessary work as the PHP ZoneInfo DB is tailored towards compatibility rather then usability. There is no user benefit in offering 6 different names for UTC or 13 different time zones for Argentina (when the whole country only uses one) or two different names for many others or a grouping of zones called "Indian" which should be called "Indian Ocean". There is certainly a potential detriment in making users decide between multiple options and wade through an unnecessarily long list. There is also certainly detriment if we instruct users to select a city when many of the available selections are in fact regions or islands or GMT offsets. Further to that point, by limiting ourselves to the verbatim names in the ZoneInfo DB we lock out translation of these geographical names into other languages and scripts, making the selection even more confusing for users who can't read english.

It would be lazy of us to simply throw up the current set of more than 450 potentially baffling options, this just passes the hard work on to the user when we could be helping them out with a smaller set of non-ambiguous options.

Don't get me wrong. I love that this feature is going into core and I appreciate the work that has been done up to now, but in it's current state it is not friendly enough for end users apart from the fact that it currently doesn't handle all cases of the transition from the old UTC offsets to the currently included GMT offsets in this new system.

#69 in reply to: ↑ 68 @Otto42
16 years ago

Replying to sambauers:

Regardless of the origin of the list (and perhaps because of the slightly unpredictable set of zones that it may contain) we need to provide a set of zones that are tailored towards greater usability, which the PHP zones are not. For a good example of a usability layer in front of the ZoneInfo DB see the Mac OS X timezone selection UI. I'm not advocating that we need a full map, just a more sensible list of cities to choose from, without duplicates and legacy names.

Absolutely not. Despite the fact that we have no way to tell (programatically) whether any given name is a duplicate or not, but also removing legacy names limits the usability of the system. For example, what if you're running a site where you make posts in the "past"? Not everybody uses WordPress in the same way that you do.

Furthermore, what you're calling "usability" is what I call "a major maintenance nightmare". It's *not* up to WordPress to maintain a list of valid timezones. All that will lead to is "why is my timezone not there" and other endless drudgery.

The whole point of switching to timezone selection using a standard is to *be standard*. To get it off of WordPress and onto PHP. If your PHP is missing a timezone, then you can simply update your system using PECL and get the latest zoneinfo list.

I feel it is necessary work

Yes, but I disagree. Not only do I think it is unnecessary, I think the idea is harmful.

There is no user benefit in offering 6 different names for UTC or 13 different time zones for Argentina (when the whole country only uses one) or two different names for many others or a grouping of zones called "Indian" which should be called "Indian Ocean".

Few things:

  1. The UTC thing is due to the inclusion of Etc, which I'm already arguing for replacing as well.
  1. Argentina has differing daylight savings rules in different areas, I presume, and thus the need for multiple sets of data. A timezone is more than just location. There's over 400 currently active timezones in the world today: http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
  1. The naming of "Indian" is not up to us, nor should it be. It is better to be consistent with a defined standard, so that people who are familiar with other software using that standard have instant intuitiveness as to what they're looking for.

There is certainly a potential detriment in making users decide between multiple options and wade through an unnecessarily long list.

Not as much so as making them look through a short list of "approved" zones only to then have to go find help when their timezone isn't there.

There is also certainly detriment if we instruct users to select a city when many of the available selections are in fact regions or islands or GMT offsets.

That's a bikeshed issue. If the wording could be better, then argue to change the wording.

Further to that point, by limiting ourselves to the verbatim names in the ZoneInfo DB we lock out translation of these geographical names into other languages and scripts, making the selection even more confusing for users who can't read english.

The names are standardized, and do not change often. If the code is modified slightly to make the city/continent names in wp_timezone_choice() translatable, then you will be able to put translations in WordPress for these in the exact same way as you translate everything else.

#70 follow-up: @sambauers
16 years ago

Clearly I'm just going to have to code a better UI for this option to get my point across. We don't have to eschew user friendliness to embrace standards, nor do we have to limit extensibility when implementing usability.

#71 in reply to: ↑ 70 @Otto42
16 years ago

Replying to sambauers:

Clearly I'm just going to have to code a better UI for this option to get my point across. We don't have to eschew user friendliness to embrace standards, nor do we have to limit extensibility when implementing usability.

I'm all for a better UI, but I'm not for needlessly removing options that I feel are important to some people.

#72 @sambauers
16 years ago

First pass at auto suggestion for timezones based on common city and country names.

Text input also accepts input of ZoneInfo zones like Australia/Sydney (including obsolete zones).

Offsets set in 2.7 will be displayed as "UTC +nn:nn" until changed. The only choice of offsets available is UTC, other than that no other manual offsets can be used.

Attachment to follow...

#73 follow-up: @ryan
16 years ago

Does auto suggest work only for the English strings?

It seems we should store the zoneinfo string to the DB and not our made up string. We should also only show an entry if it is in zoneinfo. Not all zoneinfo installs have everything. zoneinfo should be authoritative, not our array.

Maybe have an array that maps zoneinfo tz strings to our translated, pretty strings. Suggest a tz only if it is in zoneinfo. Allow someone to input a plain tz string not in our list as long as it is in zoneinfo.

#74 @ryan
16 years ago

That should be, suggest a tz only if it is in our pretty list and in zoneinfo, but allow a straight tz string if someone wants to input one as long as it is in zoneinfo.

#75 in reply to: ↑ 73 @sambauers
16 years ago

Replying to ryan:

Does auto suggest work only for the English strings?

No, it will pull suggestions from the english and the translated strings.

It seems we should store the zoneinfo string to the DB and not our made up string.

The relationship isn't one to one, so if we store say "Europe/London" the user could have initially entered "Cardiff - Wales", "Edinburgh - Scotland" or "London - England". Which means we we try to display the users initial setting we can only guess as to what they put in there in the first place. By storing the english string (not the translated string) we can put people back where they were.

We should also only show an entry if it is in zoneinfo. Not all zoneinfo installs have everything. zoneinfo should be authoritative, not our array.

The mappings from the pretty names to zoneinfo are to very safe zoneinfo entries which should be in every install. In any case the zoneinfo entry that is chosen is always tested for validity.

Suggest a tz only if it is in zoneinfo. Allow someone to input a plain tz string not in our list as long as it is in zoneinfo.

That is possible now... try entering Australia/Sydney, it works.. try entering Foo/Bar, it fails.

#76 @sambauers
16 years ago

I should note that a have attempted to recreate the same city list used by Mac OS X in it's time zone selection preference pane. So the list of cities is pretty well established as a useful subset.

#77 @ryan
16 years ago

Okay, I think that addresses my concerns then. Will do a bit more testing.

#78 @Otto42
16 years ago

Well, firstly, I hate the interface. There's absolutely no indication anywhere that a standardized zoneinfo zone will work in that field, and since the whole point is to make it *adhere to standards*, then it seems like a pretty poor UI to me.

Also, forcing the user to type their timezone in is only going to result in most people going "why doesn't my city work?" When I enter "Little Rock", for example, it fails miserably. A list of zones is necessary so the user can choose where they are... having them guess randomly until they find your "correct" zone is just awful.

Finally, your timezone list is completely wrong in many respects. I live in Memphis and the correct zoneinfo for here is "America/Chicago", not "US/Central". Using your zone results in the wrong daylight savings rules showing up. In fact, all "US" timezones should never be used, as proper zones are named by continent/city only.

So I vote thumbs down to this new interface and anything similar to it.

#79 @Denis-de-Bernardy
16 years ago

In case you missed them: be sure to check #8662, which highlights and fixes a bug related to time() related bug; and #9588, which references areas where time() calls might need to be changed in the code base.

For the UI, why not use two dropdowns?

http://deathofagremmie.com/2009/03/29/time-zone-picker-updates/

#80 follow-up: @Denis-de-Bernardy
16 years ago

Or maybe use a Google map?

http://www.gchart.com/

#82 in reply to: ↑ 80 ; follow-up: @sambauers
16 years ago

Replying to Denis-de-Bernardy:

Or maybe use a Google map?

http://www.gchart.com/

Would probably require an API key for any site unless we tied it back to the WordPress API site somehow.

#83 in reply to: ↑ 82 @Denis-de-Bernardy
16 years ago

Replying to sambauers:

Replying to Denis-de-Bernardy:

Or maybe use a Google map?

http://www.gchart.com/

Would probably require an API key for any site unless we tied it back to the WordPress API site somehow.

Dunno. I never use Google's APIs, myself. Last I checked, though Yahoo APIs were tied to an app rather than a user (the exception would be BOSS, since it's a paid-for thing). So one tied to WP might be enough.

That said, it may be worth using an image, with an image map, for this. Or something along those lines. Something visual.

Plus, accordingly to Google, WP would be the first to have this kind of UI in GPL format. :-)

#84 @Denis-de-Bernardy
16 years ago

it could be done with flash, too

#85 @Denis-de-Bernardy
16 years ago

tossing ideas... here's a thread from yui that discusses using a slider whose background is a world map:

http://yuilibrary.com/projects/yui3/ticket/2525925

#86 @ryan
16 years ago

  • Component changed from Administration to Date/Time

#87 @sambauers
16 years ago

Adding a new patch file (tz-autocomplete-2.diff) that hopefully brings us closer to resolution.

The new patch is a replacement of my previous one so should be run against an un-patched core.

Changes:

  • Better laid out time information in the settings screen
  • Removed the US/* and similar zone mappings
  • Added autocomplete for zoneinfo zones as well as the custom ones - if a slash "/" is in the text input, then it will search in zoneinfo for autocomplete suggestions
  • Added language to the description which suggests using zoneinfo if the custom names don't work out

#88 @Otto42
16 years ago

No, same problem as before. If my city isn't in your magical list, it completely fails.

The problem is with using a text entry box in the first place. There's only a certain valid set of entries, making them able to enter anything and then trying to basically guess what they need to put in isn't going to change this simple fact. All you're doing is putting a big ugly maintenance-inducing band-aid on the problem by adding a bunch more cities to the list. The problem with that: you're never going to get them all. Some are always going to be missing.

A text input makes sense when the user can validly enter anything.

Here, the user can not validly enter anything. They have a fixed set of options to choose from.

Therefore a text input makes absolutely no sense here at all.

You can't sugarcoat that.

#89 follow-up: @Otto42
16 years ago

Oh, and also, your whole UI is totally AJAX dependent. If AJAX is not working for any reason, you have no fallback. No help for the user. No hints whatsoever. They just have a blank text box with no real idea what the heck they need to type into it.

I'm sorry, but there's nothing redeeming about this UI. The dropdown with actual standard *valid* names is still far superior.

#90 @Denis-de-Bernardy
16 years ago

  • Keywords has-patch added

#91 @Denis-de-Bernardy
16 years ago

  • Keywords needs-patch added; has-patch removed

latest patch fails against today's trunk

#92 @sambauers
16 years ago

  • Keywords needs-patch removed

New patch attached in a second for current trunk

@sambauers
16 years ago

Latest for trunk at [11238]

#93 in reply to: ↑ 89 @sambauers
16 years ago

Replying to Otto42:

Oh, and also, your whole UI is totally AJAX dependent.

A lot of the admin is Javascript dependent. A fallback should be written if the patch is accepted, I'm happy to do this.

No hints whatsoever.

The note says they can enter a zoneinfo zone.

The dropdown with actual standard *valid* names is still far superior.

You keep pushing the "standards" line but adherence to standards is not the point here. For example, HTML is a standard but we don't force people to write their posts using it. We can and sometimes do provide a human usable/readable layer in front of standards if there is a perceived benefit. The idea that raw ZoneInfo names are optimum as a naming solution for the user interface is wrong. What I have provided does have faults, some of which you have pointed out, but that doesn't exclude it from consideration or make it something that we shouldn't work to improve on as a UI solution.

#94 @Otto42
16 years ago

I'm sorry, but I simply cannot see any solution that makes the user have to *guess* at the correct thing to type in as being better as giving them a list of known valid choices. Especially when that list of choices is standardized and in use in hundreds of other places all over the internet and even in their own operating systems.

#95 @Otto42
16 years ago

Let me try to explain it a different way. I use the "my mom" standard when I'm evaluating an interface element. I ask myself, "Could my mom figure this out?".

In the drop down case, it basically asks to pick a city in the same timezone as she is. She looks through them, picks one, maybe finds out it's not quite the same (since it does give the timezone changes after she selects it), and figures out the right one after maybe a couple stabs at it.

With your interface, she starts typing her town name, nothing comes up. So she types a nearby town name (biggest town within 150 miles). Sadly, nothing still comes up for her particular case. In the end, there's absolutely nothing to indicate what she has to type in. She doesn't know WTF a "zoneinfo" is. She can google that, and eventually figure out that "America/Chicago" works for her, but the point is that she has to go elsewhere to figure that out.

A dropdown makes a lot more sense. If the couple of tries bits is bothering you, then you should make the timezone changeover info feedback that appears below the box happen on an AJAX system instead of trying to make people guess. That way, they can select one, see what it is, and then change to another one to find the right one, before ever hitting the save button.

#96 @Viper007Bond
16 years ago

I'm with Otto on this one. While the dropdown solution is quite a bit to scroll through, it's a LOT easier than trying to come up with a valid city by randomly guessing about one it'll know.

I think the current implementation is going in the correct direction, but it could use some refinement. Perhaps if JS is enabled, then picking a region first (i.e. "America") to cut down on the number of items to scroll though.

#98 @Denis-de-Bernardy
16 years ago

Err, sorry: #9759 even.

#99 @Denis-de-Bernardy
16 years ago

Curious to know... why couldn't we do something like:

"Select the time it is at your current location:"

two dropdowns follow: one for hours, one for minutes (2 options: current time +0/30)... we work out the offset from there. end of story?

It would work without JS, it would remove the huge list of hard to guess options, and it also happens to be simpler than some obscure GMT offset that not everyone understands.

#100 @ryan
16 years ago

Because every nation (and sometimes states, provinces, and cities within a nation) have their own DST rules. Arizona, for example, doesn't do DST so sometimes it aligns with MST and sometimes with PDT.

#101 @ryan
16 years ago

See also #9758

#102 @ryan
16 years ago

For 2.8, I think we should go with what we have in trunk already, fix any offset problems such as #9758, and push any UI improvements to 2.9.

#103 @Denis-de-Bernardy
16 years ago

shall we close this as fixed then?

#104 @Otto42
16 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

Yep.

#105 @Otto42
16 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Got some comments from a user of my plugin that does this same basic thing, saying that his version of PHP has the necessary functions to get the list of timezones, but they don't return anything. Not sure why yet.

Suggest that we add a filter for the wp_timezone_supported function, allowing this to be manually disabled for edge cases like this.

Patch coming right up.

@Otto42
16 years ago

Adds a filter to wp_timezone_supported output

#106 @Denis-de-Bernardy
16 years ago

if we filter the value on false, might it not lead to weird results in the options screen among other things?

#107 @Otto42
16 years ago

I added it to false because it's possible somebody might want to force it to true at some future point, possibly for testing or some such thing. Since you have to actually add your own filter to force the issue, I see no problems there.

#108 @Otto42
16 years ago

Possible scenario for that case: Somebody creates their own method of adjusting the timezone, and disables ours by removing the filter on the gmt_offset option and using their own instead. Then they can force it true to enable the tz selection support.

#109 @ryan
16 years ago

  • Owner changed from anonymous to ryan
  • Status changed from reopened to accepted

#110 @ryan
16 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

(In [11329]) Allow plugins to override tz support enable/disable. Props Otto42. fixes #3962

#111 follow-ups: @matt
16 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

The dropdown UI for this is embarrassing to have in WordPress.

The problems with the AJAX UI and guessing a city can be avoided by asking people to list the nearest capital or large city.

Ultimately I think OS X has the best approach I've seen, with the map + city dropdown. Has anyone done that elegantly on the web yet?

We should also remember that currently our timezone support does not need to be 100% perfect with regards to the 400 timezones in the world, as we could create something that works better for 95% of our users and the others have it no worse than it is today.

#112 in reply to: ↑ 111 @Denis-de-Bernardy
16 years ago

Replying to matt:

Ultimately I think OS X has the best approach I've seen, with the map + city dropdown. Has anyone done that elegantly on the web yet?

See my comments above, and the couple of objections. The answer is no, and there are issues related to daylight savings.

#113 @duanestorey
16 years ago

Another random idea is to have an auto detect feature that uses the client's IP address. Chances are the server isn't in the same time zone (mine's in Dallas and I'm in Vancouver) they want it to be set as, but I imagine most users set their sites to use their own native time zone where they live (and probably are connected to the internet). You could simply ping a server, grab the IP address of the client as seen at the server, and search a geo-location database for the user's timezone and return that. Might not be 100% accurate, but might be a simple way to make a first guess.

#114 @ryan
16 years ago

  • Owner ryan deleted
  • Status changed from reopened to assigned

#115 in reply to: ↑ 111 @sambauers
16 years ago

Replying to matt:

Ultimately I think OS X has the best approach I've seen, with the map + city dropdown. Has anyone done that elegantly on the web yet?

I searched high and low previously and found nothing portable.

The patch I made almost exactly emulated the city dropdown from OSX. I'd be happy to solve the other half of the problem and incorporate a map.

We might want to separate the time options onto another page to fit it in if we did that though.

Certainly there is some clever stuff we can do via remote api calls.

#116 follow-up: @ryan
16 years ago

Keep in mind that 2.8 is frozen to the point of slushiness and that this interface will be used exactly one time and then forgotten. I once again recommend going with what we have and make it pretty later. Screwing with this now will probably delay 2.8.

#117 in reply to: ↑ 116 @sambauers
16 years ago

Replying to ryan:

Keep in mind that 2.8 is frozen to the point of slushiness

Acknowledged :)

and that this interface will be used exactly one time and then forgotten

It would be nice to think we could extend timezone handling to do some interesting things besides just setting a static timezone. I think there is some interesting stuff we can do with it in the future, allowing users to set their own timezone, auto-suggesting new timezones when an author moves around (think travel blogs). Mind you all that would be for a 2.9 or 3.0 release.

#118 @Otto42
16 years ago

I like the idea of a map selection, if there's one available. But I agree with ryan that this should be pushed back a while.

However, I do not like the idea of maintaining our own list of cities and such. It's needless and worthless bloat. If you can find a way to get the list of cities and zoneinfo zones from somewhere else, some standardized list, then fine. But we should not be building this ourselves.

Surely, somebody, somewhere, has the data in a form we can just plug and chug with?

#119 @Otto42
16 years ago

Hey, here's a *really* good example of something that might work:
http://vancouverwebconsultants.com/demos/getting-time-zone-from-latitude-longitude.php

He uses two web services, one from Google (to convert placename into lat/long), then one from Geonames (to convert lat/long into a Olson DB timezone).

With a good world map, one could figure out lat/long with a click on it, or have the user type in a city and do something similar. This, however, does rely on one or two external services, which I'm not sure we're comfortable with.

Necessary API info:
http://code.google.com/apis/maps/documentation/reference.html#GClientGeocoder
http://www.geonames.org/export/web-services.html#timezone

Thoughts on this idea? I'd be far more supportive of allowing the user to type in a place if we relied on somebody else to maintain the list of placenames.

#120 @Otto42
16 years ago

Note that the Geonames data is also available for download. I took a look at the cities > 15000 zip. It's a big table, but I think it might be possible to distill this information down to, basically, a list of lat/long/timezones, then given a lat/long, a simple nearest neighbor search through there would give you the correct timezone. So with that, we could eliminate the reliance on the Geonames webservice.

#121 @duanestorey
16 years ago

I read a post about a year ago about doing efficient geo-location searches using MySQL, and I'm pretty sure someone at Automattic wrote it. So I suspect there's already a geo-location DB accessible somewhere. Even if it's not used to do IP->Lat/Lon, it has a list of city names that could be used and translated to lat/lon. I'm pretty sure only the commercial GeoIP databases have timezone information, so it might not have that. But maybe the Geonames data would fill the gap.

There's also the world time engine API, but it's commercial:

http://worldtimeengine.com/api/ip

But it returns a lot of XML information, including UTC offset and DST.


#122 @nbachiyski
16 years ago

The map implementation is not hard. Here is a half-an-hour-worth proof of concept using <canvas>. Move your cursor over Western Europe to highlight the entire timezone slice.

There is some manual labour there:

  1. Formaly define all the slices of the map as polygons (we can add curves, too). CIA has a good map with all the timezones.
  1. Map each timezone to a slice of the map. It will take several hours of somebody's time, but it will be done just once.

@demetris
16 years ago

Kubuntu, Ubiquity installer, Timezone selection, screenshot taken from the Kubuntu wiki: https://wiki.kubuntu.org/

#124 @demetris
16 years ago

  • Cc dkikizas@… added

#125 @ryan
16 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

Great suggestions for another ticket on another day. The original issue is fixed. Closing.

Note: See TracTickets for help on using tickets.