Time Zone naming

[Scott Atwood]

The best way to find about changes to the tz database is to subscribe to and
monitor the tz mailing list:  tz at elsie.nci.nih.gov.   Upcoming changes are
typically discussed in advance of their release.

-Scott

On Fri, Dec 5, 2008 at 9:18 AM, Martin Barnes <barnes at yahoo-inc.com> wrote:

>  Thanks Scott. Yes, I better understand the provenance and status of the
> Olsen data now.
>
> I will look into the details to see the efficacy of constructing the
> roll-up zones. Since they will be neither an Olsen zone nor a CLDR metazone,
> we may have issues applying a name. The resultant data will be predominantly
> Olsen with a few roll-ups but we would want to use the Olsen name
> throughout. Reflecting on this, I think that it would be prudent to align to
> the Olsen zones otherwise we might invite problems by associating a place to
> an Olsen time zone name, when it actually belongs to a zone that has been
> rolled-up into a "superzone" for which a different name has been applied.
>
>
>
> I completely understand that the Olsen time zones change from time to time.
> New ones are added and existing ones may be modified.
>
> My question is…is there anyway of being notified when any changes occur to
> the tz database or is it a matter of systematically checking?
>
>
>
> -Martin
>
>
>  ------------------------------
>
> *From:* Scott Atwood [mailto:scott.roy.atwood at gmail.com]
> *Sent:* 04 December 2008 20:05
> *To:* Martin Barnes
> *Cc:* tz at elsie.nci.nih.gov; tz at lecserver.nci.nih.gov
> *Subject:* Re: Time Zone naming
>
>
>
> The Olson zoneinfo database and CLDR are the closest thing that presently
> exist to a standard for timezones, but they are de facto standards, not de
> jure standards administered by any kind of official international standards
> body.
>
>
>
> If it would be useful for your internal purposes, there is certainly enough
> information in the Olson data to construct "roll-up" timezones for yourself
> where the ISO-3166-2 code, GMT offset, and DST rules are all presently
> identical.  But as I mentioned below, you should expect such entities to be
> rather fluid, and you should prefer to base your implementation on the full
> fidelity Olson timezones.  Such "roll-up" timezones would be finer grained
> entities than CLDR metazones, since the only requirement for metazones is
> that they must have the same display labels.  Individual Olson timezones
> within a CLDR metazone may have different DST rules and may belong to
> different regions.
>
>
>
> Also, on the topic of future proofing, you should be prepared for the fact
> that new Olson timezones are added from time to time whenever a subregion of
> an existing zone changes its time definition independently of the rest of
> that subregion.  This happened during the recent timezone change in
> Argentina where America/Argentina/Salta split off from
> America/Argentina/Cordoba.  Any Olson update could thus potentially require
> updates to your boundary definitions.
>
>
>
> -Scott
>
>
>
> On Thu, Dec 4, 2008 at 10:48 AM, Martin Barnes <barnes at yahoo-inc.com>
> wrote:
>
>  Thanks Scott. This is very useful insight.
>
> I am really only ever concerned with expressing the current timezone for
> any given place and less worried by any need to relate to any historical
> dates and times.
>
> Consequently it was my hope to use a sanctioned standard that identified
> timezones as regions with the same political definition (ISO region code),
> the same UTC offset and the same DST rules but that ignored any historical
> context; whereby I could find and group all places that exhibited and
> experienced the same current time behaviour (such as all the cities in China
> belonging together).
>
> But it appears that no such standard exists. Furthermore, and as you point
> out in the Argentina example, using the "pure" Olsen is recommended in view
> of the frequent changes that are both "official" as decreed by governments
> and "unofficial" as adopted by local usage. Having these zones pre-defined
> as boundary map objects allows us a better degree of future-proofing against
> changes to come. That is good enough for me.
>
>
>
> I guess if I need to I might be able to create relationships between zones
> that behaved the same at any given point in time I might want to look at the
> CLDR metazones, albeit with some caution.
>
>
>
> Thanks for your time and help.
>
> -Martin
>
>
>  ------------------------------
>
> *From:* Scott Atwood [mailto:scott.roy.atwood at gmail.com]
> *Sent:* 04 December 2008 17:24
> *To:* tz at elsie.nci.nih.gov
> *Cc:* tz at lecserver.nci.nih.gov; Martin Barnes
> *Subject:* Re: Time Zone naming
>
>
>
> To the best of my knowledge, the Olson database itself does not define any
> kind of "roll-up" timezones.  The closest thing I am aware of is the CLDR
> concept of "metazones" which group together Olson timezones that share a
> common display string, like "Eastern Standard Time".  However, I believe
> these metazones can include timezones that have different DST rules.
>
>
>
> Rather than try to use "roll-up" timezones, from personal experience, I
> would urge you to use the full Olson timezone list if possible.  World
> timezone rules are highly dynamic and change with surprising frequency.  And
> it is not uncommon for two Olson timezones to have the same GMT offset and
> DST rules in one release of Olson, but then have different rules in a future
> release.   The example that you cite, Argentina, is an excellent example.
>  Until just a few weeks ago, all of Argentina was effective under the same
> set of time zone rules, but when the central government decided to observe
> DST this year, several of the states decided to remain in standard time.  An
> application that had assigned "America/Argentina/Buenos_Aires" to everyone
> in Argentina regardless of their actual Olson timezone would have broken.
>
>
>
> Also note that it can be useful to maintain the separate timezones if your
> application needs to format and display historical dates and times, as in
> logging or transaction history.  Timezones that have the same GMT offset and
> DST rules today may have had different rules in the past, and having the
> most accurate timezone means you could display the historical records
> correctly as well.
>
>
>
> -Scott
>
>
>
>
>
> From: Martin Barnes [mailto:barnes at yahoo-inc.com]
> Sent: Friday, November 28, 2008 11:48
> To: tz at lecserver.nci.nih.gov
> Subject: Time Zone naming
>
> I have a question related to the accepted standard for expressing the
> "Olsen" name where multiple zones exhibit the same "behaviour" in terms
> of belonging to the same country, having the same UTC offset and exactly
> the same DST rules.
>
> For example, it appears that all clocks within all locations within
> Argentina will have the same time all year round. The 12 zones reveal
> the same behaviour. The same is true of China and a number of other
> countries.
> I have been aware of the concept of a "consolidated" or "preferred" time
> zone which is a combined zone that takes the name of the most important
> location (eg. "America/Buenos_Aires" in the case of Argentina)
>
> Do these combined "super" zones exist? If so, is there information
> available that indicates how the individual zones roll up?
>
> My enquiry relates to a need to provide information that can identify
> the correct timezone for every place (city, postcode, county, state, etc
> etc) on earth via a back-end mapping service that calculates the spatial
> relationship between the place coordinate and the timezone boundary.
> I am looking to build up an accurate timezone boundary map essentially
> using existing map objects as building blocks.
>
> Many thanks
> -Martin Barnes
> ______________________
> GeoData Manager
> Yahoo! Geo Technologies
> Geo Informatics team
> London
>
>
>
>
> --
> Scott Atwood
>
> Cycle tracks will abound in Utopia.  ~H.G. Wells
>
>
>
>
> --
> Scott Atwood
>
> Cycle tracks will abound in Utopia.  ~H.G. Wells
>
>


-- 
Scott Atwood

Cycle tracks will abound in Utopia.  ~H.G. Wells
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20081205/718d80b4/attachment-0001.html