[wp-trac] Re: [WordPress Trac] #3962: WordPress should adjust for DST ("location" appropriate)

[WordPress Trac]

#3962: WordPress should adjust for DST ("location" appropriate)
----------------------------+-----------------------------------------------
 Reporter:  iacas           |        Owner:  anonymous
     Type:  task (blessed)  |       Status:  reopened 
 Priority:  high            |    Milestone:  2.8      
Component:  Administration  |      Version:  2.1.2    
 Severity:  normal          |   Resolution:           
 Keywords:  needs-testing   |  
----------------------------+-----------------------------------------------

Comment(by Otto42):

 Replying to [comment:68 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.

 2. 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

 3. 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.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/3962#comment:69>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software