- tz - lists.iana.org

TimeZine Info Problem
by dcernosia＠aol.com April 8, 2013

April 8, 2013

Guys, Ran into a little problem when I tried to process the latest TimeZone files ... a few rules, such as the one listed below, didn't process correctly ... I think there are extra tabs separating the data ... have you had any other complaints? Morocco 2013 only - Jul 9 3:00 0 Morocco 2013 only - Aug 8 2:00 1:00 S Morocco 2016 only - Jun 7 3:00 0 Morocco 2016 only - Jul 7 2:00 1:00 S Morocco 2019 only - May 6 3:00 0 - Morocco 2019 only - Jun 5 2:00 1:00 S Morocco 2022 only - May 3 2:00 1:00 S Thanks, - Dennis

3 2

Rule based management vs TZ Coordinator will or voting / fork reason
by Tobias Conradi April 8, 2013

April 8, 2013

Emails such as the recent ones about ambiguous time zone acronyms can be avoided if the management of the database would be more rule based. It seems there is no rule prohibiting one abbreviation from referring to two offsets within one country at a given point in time. So adding a rule to the Theory file prohibiting this would be one step. The other issue is, that if rules exists, e.g. ftp://ftp.iana.org/tz/code/Theory ----- Scope of the tz database ----- The tz database attempts to record the history and predicted future of all computer-based clocks that track civil time. To represent this data, the world is partitioned into regions whose clocks all agree about time stamps that occur after the somewhat-arbitrary cutoff point of the POSIX Epoch (1970-01-01 00:00:00 UTC). that they are also enforced. But the TZ Coordinator is sometimes not enforcing them, as the Siberia bug (Asia/Tomsk and Asia/Barnaul patch was provided to the list) shows. Arbitrary application of rules can be a fork reason. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

1 0

Ambiguous abbreviations for Australian timezones when daylight savings is in affect [SEC=UNCLASSIFIED]
by Peter Stagg April 8, 2013

April 8, 2013

Thanks to David et al for taking this initiative. In respons to the specific questions posed: - would the preference be to preceed the abbreviations with A, or not? I think the 'A' is most apropriate and is in keeping with my understanding of conventioned followed in Australia. It would also be very easy to deal with in the situation where a programer may want to drop the 'A' - historically, how far back should we apply the patch to the abbreviations. I'm in favour of retro-fitting it to the start of Daylight Savings in Australia (sate-based dependancies taken into account). After all its a bit like BC and AD. If you we're wandering around in 200BC you had no idea it was 200BC but today we would not refer to it as anything else (unless you don't use the christian calendar, of course). ________________________________________ Date: Sun, 07 Apr 2013 21:19:36 -0400 From: David Patte ? <dpatte(a)relativedata.com> Subject: Re: [tz] Ambiguous abbreviations for Australian timezones when daylight savings is in affect [SEC=UNCLASSIFIED] To: tz(a)iana.org Message-ID: <51621B28.4030105(a)relativedata.com> Content-Type: text/plain; charset=UTF-8; format=flowed A group of us from the list have decided to put together a proposed patch to change the Australian abbreviations to S/D abbreviations. We are hoping, that the maintainers of tz decide to implement the patch in the tz database. In the mean time: - would the preference be to preceed the abbreviations with A, or not? - historically, how far back should we apply the patch to the abbreviations. We will submit the patch to the list for review, and hope it is implemented. But if it is not, we have decided to fork tz and provide a new distribution with the new abbreviations applied. David Patte Relative Data, Inc. _______________________________________________

1 0

Re: [tz] Ambiguous abbreviations for Australian timezones when daylight savings is in affect [SEC=UNCLASSIFIED]
by Peter Stagg April 8, 2013

April 8, 2013

"Lies, damned lies, and statistics" - I guess it depends on how you cut the cloth: search: legislation "standard time" "daylight saving" site:.gov.au About 25,600 results (0.21 seconds) search: legislation "standard time" "summer time" site:.gov.au About 15,600 results (0.14 seconds) Yes in some cases you will find the following: 'daylight saving time ("summer time")'; that to me supports the notion of "daylight saving" ahead of "summer time". N.B. ".gov.au" searches all state and federal official sites as they all use this domain. (e.g. Federal = just .gov.au, State i.e. Victoria = .vic.gov.au ). I've noticed through my various searches of government websites that whilst the legislative instruments for time may often use the term "Summer Time" (Vic & NSW only) their public facing information sites use the term "Daylight Saving". http://www.nsw.gov.au/daylight-saving http://www.business.vic.gov.au/operating-a-business/how-to-start/trading-ho… http://australia.gov.au/about-australia/our-country/time http://www.dpac.tas.gov.au/divisions/policy/daylightsavings http://www.cmd.act.gov.au/communication/holidays http://www.safework.sa.gov.au/show_page.jsp?id=2675 WA, QLD and NT do not have daylight savings but still: http://www.premiers.qld.gov.au/publications/categories/reports/daylight-sav… http://www.parliament.wa.gov.au/parliament/bills.nsf/BillProgressPopup?open… And yes these are cherry-picked - to the most part these ar all public facing official government pages communicating to the Australian populous about "Daylight Saving" not "Summer Time" - if "Summer Time" was lingua franca, don't you think they (we) would use it? Peter Stagg

1 0

Please remove ambiguous time zone abreviations for Australia [SEC=UNCLASSIFIED]
by Robert Greenwood April 8, 2013

April 8, 2013

Hi all, I know this might sound like a broken record to some, but could we please remove ambiguous time zone abreviations for Australia? I can't for the life of me understand why anyone would want to keep the Australian zones as EST/EST and CST/CST rather than EST/EDT and CST/CDT or AEST/AEDT and ACST/ACDT. Stating that there in no need to change it is nonsensical. It is obvious that using the abbreviation Eastern Standard Time (EST) and Eastern Summer Time (EST) is useless at best. The fact that if you have time zones you need them to be unambiguous is self evident, otherwise why have them. Stating that there are conflicting messages from state and federal government regarding the use of time zones in Australia is misleading. No State or federal government proposes the use of EST/EST and CST/CST as the correct usage of time zone abbreviations. Whilst there is some inconsistency in the usage of AEDT/EDT/EDST within those sites when they explicitly state which time zone should be used it is AEST/AEDT and ACST/ACDT. Finally, the arguments around the usage of Eastern/Central Summer Time (EST/CST) being the status Quo amongst Australians based off the survey conducted in the following linked is flawed: http://mm.icann.org/pipermail/tz/2012-October/018364.html searching for EDT or EST by themselves will return a number of things that have no relation to time zones. Similarly, "Eastern Summer Time" and "Eastern Daylight Time" do not necessarily relate to the usage of a particular abbreviation. Searching for the number of hits for the following strings gives a better understanding of the usage of the relevant time zone acronyms in Australia: Google results for au domain: 45,100: "Eastern Standard Time (EST)" 82,400: "Eastern Standard Time (AEST)" 34,900: "Eastern Summer Time (EST)" 117: "Eastern Summer Time (AEST)" 72,100: "Eastern Daylight Time (EDT)" 218,000: "Eastern Daylight Time (AEDT)" 387,000: "Central Standard Time (CST)" 8,030: "Central Standard Time (ACST)" 3: "Central Summer Time (CST)" 3: "Central Summer Time (ACST)" 22,300: "Central Daylight Time (CDT)" 1,460: "Central Daylight Time (ACDT)" Here we are only looking at cases where the time zone abbreviation has been defined. These results show that the abbreviation for Daylight time EDT/AEDT/CDT/ACDT is overwhelmingly greater than the usage of the abbreviation for Summer time EST/AEST/CST/ACST. Furthermore, varients of the search for "Eastern Daylight Saving/s Time (A/EDT)" give another ~3,000 hits and variants of "Eastern Daylight Saving/s Time (A/EDST)" only give ~ 500 results. However, a cursory glance still shows that many of these results are not related to Australia. So this method is still flawed but I cannot think of a better way of searching for the status Quo. Please change the time zone abbreviations in Australia to EST/EDT and CST/CDT or AEST/AEDT and ACST/ACDT. ----------------------------------------------------------------------------- Dr Robert Greenwood | Tsunami Modelling Support National Meteorological and Oceanographic Centre Bureau of Meteorology GPO Box 1289 Melbourne VIC 3001 Level 11, 700 Collins Street, Docklands VIC 3008 Tel: +61 3 9616 8455 | r.greenwood(a)bom.gov.au<mailto:r.greenwood@bom.gov.au> -----------------------------------------------------------------------------

2 1

White House petitioned to end DST
by Arthur David Olson April 4, 2013

April 4, 2013

An electronic petition to "Eliminate the bi-annual time change caused by Daylight Savings [sic] Time" appears at... https://petitions.whitehouse.gov/petition/eliminate-bi-annual-time-change-c… ...and as of this writing has about 6,000 of the 100,000 electronic signatures required for an official White House response. @dashdashado

3 3

How to compute the moment of the next DST change
by Simon Perreault April 4, 2013

April 4, 2013

Dear time experts, I want to write a cron job or similar that activates one week prior to daylight saving time changes. (Or, more generically, one week prior to any time jumps, for any reason, DST or else.) Any pointers? I have looked at the usual places: POSIX time functions, various date/time modules on CPAN, etc. Nothing seems to do that computation. Do I need to parse the tz database myself? Thanks, Simon

14 20

Ambiguous abbreviations for Australian timezones when daylight savings is in affect
by Timothy Arceri April 4, 2013

April 4, 2013

Hi All, I’d like to bring this very important issue back up for discussion. I’m going to attempt to address the reason why this change is needed as clearly as possible while addressing the concerns from previous discussions. The issue is with both EST (Tasmania, Victoria, New South Wales, Queensland) and CST (South Australia, Northern Territory) It's well past time the Australian abbreviations were updated to reflect the current terms and usage. Stop the confusion and use the abbreviations recommended by the Australian government to try to avoid this mess. http://australia.gov.au/about-australia/our-country/time#daylightsaving As others have posted I’m not too concerned about the 'A' but as you will see differentiating between daylight savings times is extremely important when you are using this information in a system that crosses state boundaries and in our case an emergency warning system. Previous Post: --------------------- “I'm not a big fan of change for change's sake; once the database is one way I like to leave it alone. For phrases, the new statistics seem to be quite strong; for whatever reason, Australians seem to be voting with their feet (or fingers) and are adopting American terminology with an "Australian", when the time zone names are spelled out. For abbreviations, it's not clear whether "AEDT" or "EDT" is more common, though I suppose "AEDT" has a slight edge. I'd like to hear more from Australian correspondents on this before thinking about specific changes, though.” - Paul Eggert (26 Aug 2008) I don’t think anyone here cares deeply enough about time zone abbreviations enough to be arguing about change for change’s sake. The fact is the ambiguity of the current abbreviations for time zones is causing real world problems. Previous Post: --------------------- “Alphabetic time zone abbreviations should not be used as unique identifiers for UTC offsets as they are ambiguous in practice. For example, "EST" denotes 5 hours behind UTC in English-speaking North America, but it denotes 10 or 11 hours ahead of UTC in Australia; and French-speaking North Americans prefer "HNE" to "EST".” - Paul Eggert (26 Aug 2008) The issue is not that the identifiers are not unique worldwide. The problem is that they are not unique to bordering states in the same country which run along the same time zone. Most apply daylight savings time, one (Queensland) does not, this is what causes the confusion. Simply using UTC +10 or UTC +11 is not good enough as the general public has no idea what UTC is. Previous Post: --------------------- “I have always assumed that the common abbreviation (EST for standard time, and EST for summer time) was a very deliberate choice, chosen so that if it ever was appropriate to specify a time with an abbreviated zone name, then the time specified would apply year around, which is almost always what is intended” - Robert Elz (5 Jan 2009) If all states that used EST applied daylight saving then this would be convenient but as stated above they do not. The problem can be seen in the delivery example where it would appear an Australian company does delivery’s via time travel. Previous Post: --------------------- “Queensland don't have Daylight Saving Time. New South Wales (across the border from Queensland) do have Daylight Saving Time. Due to the fact that the Olsen data uses EST for both 'Eastern Summer Time' (New South Wales) and 'Eastern Standard Time' (Queensland), a delivery from New South Wales to Queensland can have a pickup time of 10.30am EST and a delivery time of 10.00am EST. We like to be efficient but we're not that good. System users only see the EST and get horribly confused.” - Mick Johnston (26 Aug 2008) So obviously I’m pushing this for my own reason also. We currently use unix based systems to produce tsunami arrival times for the Australian Tsunami Warning System. This information is displayed on a public webpage (and as described above cannot use UTC convention). The issue comes into play when listing arrival times for the east coast of Australia, simply listing all arrival times as EST will obviously cause confusion especially for towns located near the border of NSW/QLD where it would appear to take a tsunami an extra hour to arrive only a couple of kilometres away. Currently we cannot use the default unix time zone commands and must rely on the use of a script to parse the time zone files and produce EST/EDT abbreviations. Obviously the ideal solution is to fix the EST/CST abbreviations once and for all so the all Australians can finally have software that produces time zones abbreviations that can be read by the general public and be used without having to provide added context. Note: In our organisation alone this issue has been brought up independently by multiple areas. Timothy Arceri

28 98

Acronyms - localization - more CLDR failures
by Tobias Conradi April 3, 2013

April 3, 2013

On Wed, Apr 3, 2013 at 12:56 AM, Derick Rethans <tz(a)derickrethans.nl> wrote: >> I disagree. I think it's natural to want to abbreviate, especially >> with things that are repeated a lot. > > But that has to be done in a localized way anyway. With the default local being English in the IANA time zone database. > In the Netherlands, > nobody uses CEST or CET, but rather MEZT and MET... Sure? https://www.google.com/search?q=cet+central+site%3Anl And CLDR does not even have MEZT and MET for the Dutch language as you claim is exclusively used in the Netherlands: http://www.unicode.org/repos/cldr/trunk/common/main/nl.xml <metazone type="Europe_Central"> <long> <generic>Midden-Europese tijd</generic> <standard>Midden-Europese standaardtijd</standard> <daylight>Midden-Europese zomertijd</daylight> </long> <short> <generic>CET</generic> <standard>CET</standard> <daylight>CEST</daylight> </short> </metazone> > but the tz database > doesn't have those either. The localization and naming is done very well > in CLDR. Counter evidence (Failure on Mexico / Tiempo del Pacifico) has been shown. > I have implemented the Date/Time support (utilizing this > database) in PHP, and have given many presentations about the subject. Ever in front of Mexicans showing Spanish localization for Mexico or in front of Dutch speakers showing Dutch localization for Central Europe? > I > always hammer in two things: .... never > rely or use an abbreviation for anything. Why not? CET in the context of Europe always refers to "Central European Time", doesn't it? Same may go for WAT in Africa and West Africa Time. As seen with AxT representing AxST/AxDT in Australia, the acronyms are not all usable in the IANA time zone database, but duplicating information and inventing new IDs like Europe_Central (=CET), America_Pacific (US and CA = America?) as is done in http://unicode.org/repos/cldr/trunk/common/supplemental/metaZones.xml seems like creating a field for having more bugs. Let's check Shanghai: http://en.wikipedia.org/wiki/Time_in_China In mainland China standard time is called Beijing Time (北京时间) https://www.google.com/search?q="北京时间" ~ 57 mio results http://unicode.org/repos/cldr/trunk/common/supplemental/metaZones.xml <timezone type="Asia/Shanghai"> <usesMetazone mzone="China"/> </timezone> http://www.unicode.org/repos/cldr/trunk/common/main/zh.xml <metazone type="China"> <long> <generic>中国时间</generic> <standard>中国标准时间</standard> <daylight>中国夏令时间</daylight> </long> </metazone> 中国 = China https://www.google.com/search?q="中国时间" ~ 1 mio results https://www.google.com/search?q="中国标准时间" ~ 230 000 results http://www.unicode.org/repos/cldr/trunk/common/main/en.xml <metazone type="China"> <long> <generic>China Time</generic> <standard>China Standard Time</standard> <daylight>China Daylight Time</daylight> </long> </metazone> No acronyms at all! -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

1 0

A failure - CLDR as an IANA time zone database extension for Mexico
by Tobias Conradi April 2, 2013

April 2, 2013

Tiempo del Pacifico http://es.wikipedia.org/wiki/Zonas_horarias_de_M%C3%A9xico#Tiempo_del_Pac.C… Tiempo del Pacifico -6/-7 confirmed by http://www.cenam.mx/hora_oficial/ Tiempo del Pacífico = UTC(CNM) – (N+1) Donde N es 6 horas para el horario de invierno y 5 horas para el horario de verano. ==Test 1 - Tijuana== The only Pacific that I can find in http://www.unicode.org/repos/cldr/trunk/common/main/es.xml outside the Area/Locations names are in that section: <metazone type="America_Pacific"> <long> <generic>Hora del Pacífico</generic> <standard>Hora estándar del Pacífico</standard> <daylight>Hora de verano del Pacífico</daylight> </long> </metazone> An example zone for America_Pacific from http://unicode.org/repos/cldr/trunk/common/supplemental/metaZones.xml mapZone other="America_Pacific" territory="MX" type="America/Tijuana"/ Look America/Tijuana up in ftp://ftp.iana.org/tz/data/zone.tab America/Tijuana US Pacific Time - Baja California near US border ftp://ftp.iana.org/tz/data/northamerica -8:00 Mexico P%sT 2010 -8:00 US P%sT ==Example 2 - Hermosillo== ftp://ftp.iana.org/tz/data/zone.tab America/Hermosillo Mountain Standard Time - Sonora -7:00 Mexico M%sT 1999 -7:00 - MST That is "Tiempo del Pacífico", using http://www.cenam.mx/hora_oficial/ Tiempo del Pacífico = UTC(CNM) – (N+1) Donde N es 6 horas para el horario de invierno .... http://unicode.org/repos/cldr/trunk/common/supplemental/metaZones.xml <timezone type="America/Hermosillo"> <usesMetazone to="1970-01-01 08:00" mzone="America_Pacific"/> <usesMetazone from="1970-01-01 08:00" mzone="America_Mountain"/> </timezone> http://www.unicode.org/repos/cldr/trunk/common/main/es.xml <metazone type="America_Mountain"> <long> <generic>Hora de las Montañas</generic> <standard>Hora estándar de Montaña</standard> <daylight>Hora de verano de Montaña</daylight> </long> </metazone> -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

3 2