[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 sambauers):

 Replying to [comment:67 Otto42]:
 > Replying to [comment:65 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.

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