#3962 closed task (blessed) (fixed)
WordPress should adjust for DST ("location" appropriate)
Reported by: | 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 )
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)
Change History (136)
#1
follow-up:
↓ 2
@
18 years ago
- Keywords reporter-feeback added
- Milestone 2.1.3 deleted
- Priority changed from high to normal
#2
in reply to:
↑ 1
;
follow-ups:
↓ 3
↓ 4
@
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
@
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
@
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:
↓ 6
@
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:
↓ 7
↓ 8
@
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:
↓ 9
@
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
@
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
@
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
@
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
@
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
#13
@
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
@
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
#17
@
17 years ago
- Keywords hunt-irrelevant removed
- Resolution set to invalid
- Status changed from new to closed
#18
@
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
@
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
@
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:
↓ 22
@
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
@
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.
#24
@
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
@
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
@
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.
#28
@
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
@
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.
#30
@
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:
↓ 32
@
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
@
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.
#35
@
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.
#37
follow-ups:
↓ 38
↓ 41
@
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
@
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
@
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
@
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
@
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
@
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).
#46
@
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.
#47
@
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.
#50
@
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.
#51
@
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:
↓ 53
@
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:
↓ 56
@
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
@
16 years ago
A patch, which doesn't break a single phrase into several translatable strings. Please, don't do that.
#56
in reply to:
↑ 53
@
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
@
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
@
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
@
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
@
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.
#63
@
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.
#65
follow-up:
↓ 67
@
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
@
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:
↓ 68
@
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:
↓ 69
@
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
@
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:
- The UTC thing is due to the inclusion of Etc, which I'm already arguing for replacing as well.
- 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
- 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:
↓ 71
@
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
@
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
@
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:
↓ 75
@
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
@
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
@
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
@
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.
#78
@
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
@
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/
#81
@
16 years ago
other map example: http://www.cretetravel.com/world_time_zones.htm
#82
in reply to:
↑ 80
;
follow-up:
↓ 83
@
16 years ago
Replying to Denis-de-Bernardy:
Or maybe use a Google map?
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
@
16 years ago
Replying to sambauers:
Replying to Denis-de-Bernardy:
Or maybe use a Google map?
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. :-)
#85
@
16 years ago
tossing ideas... here's a thread from yui that discusses using a slider whose background is a world map:
#87
@
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
@
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:
↓ 93
@
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.
#91
@
16 years ago
- Keywords needs-patch added; has-patch removed
latest patch fails against today's trunk
#93
in reply to:
↑ 89
@
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
@
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
@
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
@
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.
#99
@
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
@
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.
#102
@
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.
#105
@
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.
#106
@
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
@
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
@
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.
#111
follow-ups:
↓ 112
↓ 115
@
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
@
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
@
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.
#115
in reply to:
↑ 111
@
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:
↓ 117
@
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
@
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
@
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
@
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
@
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
@
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
@
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:
- Formaly define all the slices of the map as polygons (we can add curves, too). CIA has a good map with all the timezones.
- 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.
@
16 years ago
Kubuntu, Ubiquity installer, Timezone selection, screenshot taken from the Kubuntu wiki: https://wiki.kubuntu.org/
#123
@
16 years ago
Another good implementation is in the Ubiquity installer:
<http://core.trac.wordpress.org/attachment/ticket/3962/kubuntu-ubiquity-where-are-you.png>
The slices are here:
<http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/files/head:/pixmaps/timezone/>
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.