- tz - lists.iana.org

Nagorno-Karabakh rejects daylight saving time
by Alexander Krivenyshev March 24, 2012

March 24, 2012

According to news Nagorno-Karabakh (de facto independent republic, disputed between Armenia and Azerbaijan) is abolishing Daylight Saving Time. about Nagorno-Karabakh http://en.wikipedia.org/wiki/Nagorno-Karabakh_Republic (in Russian) Nagorno-Karabakh rejects daylight saving time. http://nbnews.com.ua/news/34302/ http://www.kavkaz-uzel.ru/articles/203632/ some translation from Russian: According to the Department of Information and Public Relations of the government of Nagorno-Karabakh, the government void decision "On a new procedure for the calculation time of the Nagorno-Karabakh" (October 25, 1996), which used to regulate transition to DST or (brief) http://www.worldtimezone.com/dst_news/dst_news_nagorno-karabakh01.html P.S. Armenia will not observe DST in 2012 and Azerbaijan begins DST on March 25, 2012. Alexander Krivenyshev- WorldTimeZone.com http://www.worldtimezone.com

1 0

Re: [tz] changes to AusAQ [SEC=UNCLASSIFIED]
by Michael Chinn March 23, 2012

March 23, 2012

Took me awhile to get around to compiling the data, can only get it back to 2010 at present Casey 24/10/2010 5:00 +11 Wilks Aero 24/10/2010 5:00 +11 Davis 24/10/2010 7:00 +5 Casey 6/03/2011 5:00 +8 Wilks Aero 6/03/2011 5:00 +8 Davis 6/03/2011 2:00 +7 Casey 22/10/2011 7:00 +11 Wilks Aero 22/10/2011 7:00 +11 Davis 22/10/2011 7:00 +5 Casey 22/02/2012 4:00 +8 Wilks Aero 22/02/2012 4:00 +8 Davis 22/02/2012 1:00 +7 Best regards, Michael Michael Chinn IT Help Desk Australian Antarctic Division p: (03) 6232 3488 e: michael.chinn(a)aad.gov.au<mailto:michael.chinn@aad.gov.au> w: www.antarctica.gov.au<http://www.antarctica.gov.au/> [cid:image001.jpg@01CD08EE.D0F50690]<http://centenary.antarctica.gov.au/> ___________________________________________________________________________ Australian Antarctic Division - Commonwealth of Australia IMPORTANT: This transmission is intended for the addressee only. If you are not the intended recipient, you are notified that use or dissemination of this communication is strictly prohibited by Commonwealth law. If you have received this transmission in error, please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209 and DELETE the message. Visit our web site at http://www.antarctica.gov.au/ ___________________________________________________________________________

1 0

Eternal DST rules for Morocco from 2012 at last
by OvV_HN March 21, 2012

March 21, 2012

In reply to: [tz] Eternal DST rules for Morocco from 2012 at last Arthur David Olson arthurdavidolson at gmail.com Wed Mar 21 11:09:40 UTC 2012 I've attached an updated proposed change for Morocco; the tabs-mangled-by-Gmail version appears below. The differences are against 2012b. --ado diff -r -c old/africa new/africa .............. etc. Reply: In Morocco DST will not be observed during the month of Ramadan. This will happen approximately from 2012-7-20 to 2012-8-18. See my posting from a couple of days ago (Mar 16). Your TZ update does not reflect this situation. Any reason why? Oscar van Vlijmen

2 1

Re: [tz] Eternal DST rules for Morocco from 2012 at last
by Dan Abitbol March 21, 2012

March 21, 2012

Hello Sorry to disturb again but as you know Morocco have new DST rules and first change is scheduled on 25 March 15, 2012-03-15 Do you plan to release 2012c that takes into account these new rules for Morocco soon ? We really need them to get Red Hat publish new tzdata rpm and PHP Pecl to publish new timezone db extension from your official files And then we need to update more than 40 machines at one of our customers in Morocco Please help. Thank you very much -----Message d'origine----- De : Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Envoyé : lundi 12 mars 2012 18:38 À : 'Dan Abitbol' Objet : RE: Eternal DST rules for Morocco from 2012 at last Robert Elz has been serving as the coordinator since October of last year. --ado -----Original Message----- From: Dan Abitbol [mailto:dabitbol@streamwide.com] Sent: Monday, March 12, 2012 1:33 To: Olson, Arthur David (NIH/NCI) [E] Subject: RE: Eternal DST rules for Morocco from 2012 at last Thank you very much After I read the thread about it , I understood that you were no more the Tz Coordinator and that there's no yet anyone doing this role (although zefram applied) , is my understanding correct ? Regards -----Message d'origine----- De : Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Envoyé : lundi 12 mars 2012 18:26 À : 'Dan Abitbol' Objet : RE: Eternal DST rules for Morocco from 2012 at last Your best bet is to subscribe to the new IANA time zone mailing list; I expect word on an update will appear there shortly. --ado -----Original Message----- From: Dan Abitbol [mailto:dabitbol@streamwide.com] Sent: Monday, March 12, 2012 1:20 To: Olson, Arthur David (NIH/NCI) [E]; 'Derick Rethans' Cc: support(a)streamwide.com; 'Serban NISTOR'; amajjad(a)streamwide.com Subject: RE: Eternal DST rules for Morocco from 2012 at last Hello Mr Olson It's not you anymore who apply the changes and makes new timezone db package available for all ? is it someone else at IANA ? How to get please the 2012c early this week with updated rules for Morocco ? Do you think we have a chance to get it this week or some days before 25 march ? In fact, I could apply the changes by hand and update red hat timezone db files but actually, I guess Dereck will need official timezonedb 2012c to produce sources file for the php extension that we would have to recompile . Thank you for any help. Regards -----Message d'origine----- De : Olson, Arthur David (NIH/NCI) [E] [mailto:olsona@dc37a.nci.nih.gov] Envoyé : lundi 12 mars 2012 18:13 À : 'Dan Abitbol'; 'Derick Rethans' Cc : support(a)streamwide.com; 'Serban NISTOR'; amajjad(a)streamwide.com Objet : RE: Eternal DST rules for Morocco from 2012 at last You can wait for 2012c, or you can pick up the change from the mailing list archive and apply it by hand. --ado -----Original Message----- From: Dan Abitbol [mailto:dabitbol@streamwide.com] Sent: Monday, March 12, 2012 1:05 To: 'Derick Rethans' Cc: support(a)streamwide.com; Olson, Arthur David (NIH/NCI) [E]; 'Serban NISTOR'; amajjad(a)streamwide.com Subject: RE: Eternal DST rules for Morocco from 2012 at last Thank you Derick So I just have to wait for 2012c ?

8 11

Easy conversion to MySQL?
by Yann Gascard / VPA President March 21, 2012

March 21, 2012

Hello, I'm normally using MySQL timezone description table (http://dev.mysql.com/downloads/timezones.html) But lately they are not that reactive there. Is anybody able to help me finding a way to generate these description table easily by myself? I got to use them as hosting provider I've got is not updating PHP timezones and I need an up to date reference. I don't have a Unix system. I can access to a Mac OS X one but even this one is really out of date (even with a system up to date). So I can't generate the tables using the mysql_tzinfo_to_sql there either :(** <http://dev.mysql.com/doc/refman/5.5/en/mysql-tzinfo-to-sql.html> Thanks a lot! :) -- -- *Yann Gascard* - President Virtual Pilots Association www.virtualpilots.org <http://www.virtualpilots.org>

2 1

Re: [tz] TZ from lat/lon?
by H J March 20, 2012

March 20, 2012

--- On Thu, 3/1/12, David Patte <dpatte(a)relativedata.com> wrote: > Time Zone Master, from relativedata.com, is a windows program that does > this type of calculation internally. [...] > The programme is free from our site, and is packaged as a desktop clock > application, but if you are looking for a more specific product for your > needs, the internal latlong->tz engine could be rebuilt into something > more suitable. Let me know what you are looking for. Hi David, Thanks for responding, and sorry I have been so slow in getting back to you (work travel the past few weeks; just now catching up). The Windows app looks terrific, but my little project will need to run on a small embedded Linux board (Gumstix Overo or similar), so I think it's really the internal engine I would want to use. (And in case it matters, this is a one-off personal project I'd been thinking of doing for some time now, so it's strictly non-commercial.) Regards, --HJ

1 0

TZ from lat/lon?
by H J March 20, 2012

March 20, 2012

Hello all, Not sure if this is the best place to ask this (and if not, I would be very thankful for any suggestions), but does anyone know of a decent open source lat/lon-to-timezone package that runs _standalone_ (as opposed to querying a server somewhere)? I am aware of a few networked solutions (e.g. earthtools) and at least one commercial package (askgeo). The former won't work standalone, while the site license for the latter is too steep for my noncommercial, one-off project. Thanks very much in advance, HJ

4 6

TZ Coordinator candidate
by Zefram March 17, 2012

March 17, 2012

With ado's retirement now almost upon us, I'd like to volunteer for the role of TZ Coordinator. Although I've only been directly involved, on the mailing list, for half a year, I've been peripherally involved for much longer. I'm very comfortable working in this space, and I believe I have the right personal qualities for the job. Firstly, I have a strong and unshakeable inclination to attend to detail, a determination to be thorough, and a decisive concern for correctness. (The former, at least, is an autistic trait, one of several that turn out to be useful to engineers.) I believe these qualities have been apparent in my contributions to the mailing list in recent months. For further substantiation, see my published code and contributions to other mailing lists (links below). I have a calm temperament, which kre rightly identified (on 2009-09-04) as a vital quality for this role. This can be seen in action on the various other mailing lists that I have inhabited in recent years. Particularly see the leap seconds mailing list, where in the past couple of years many discussions have regrettably become much more heated than befits the calibre of participant, and perl5-porters, where I've occasionally dealt with a prickly CPAN author. I'm at the right point in my career to take on this sort of role, potentially for as long as ado has served. I'm mature enough to take on a long-term commitment, while still young enough to have a long term. I was born in 1977, and so am some thirty years away from pensionable age. I can't promise to actually serve for that long, but there isn't anything standing in the way of me doing so. I have, and use, network access nearly every day, so I can respond promptly to urgent issues. I read email, as it comes in, during most of my waking hours, and I'm similarly available on IRC. I tend to spend my weekends and holidays (from paid work) programming. I don't make a habit of travelling, though I presently attend an annual conference that occupies me for five consecutive days. (I haven't so far attempted to access the net while at a conference, but it is available at these conferences, and I ought to get with the times.) Although it's not strictly necessary in a TZ Coordinator, I'm technically well qualified to look after the timezone code. C was my main programming language for about ten years, 1988 to 1998. Since then my main language has been Perl, but I still regularly work in C. About half of the Perl modules that I've published are largely implemented in C, for one reason or another, and I'm a contributor to the Perl core, which is written in C. The quality of my code can be discerned by perusal of my published Perl modules. I have a deep and abiding interest in horology, and particularly in computer implementation of it. I've been on the leap seconds mailing list for some years, actively involved in many discussions there. In the Perl world much of my published code is concerned with time, and last year I gave a well-received talk about time (but not timezones) at two Perl conferences (video link below). Looking more specifically at timezones, some of my Perl code is about timezones, much of that specifically about using the TZ database. I've become intimately familiar with the database through my work on this code. As a bonus, I have some plans for how the database should develop from where it is now. Chief among them, I'd like to see it become more historically comprehensive, but there are obvious problems for users that would come from multiplying up the number of timezones on the present infrastructure. I've got some clear ideas about how to solve these problems, principally some concepts for a new tzfile format that would let zones share representation. I'm confident of the feasibility, and I'd like to develop in this direction with a view to supplanting the present implementation, applying all due caution for stability issues. It's not necessary for me to be the TZ Coordinator in order to proceed with such a project, and I hope to do so anyway, but there's some level of convenience in the roles being colocated. In the spirit of openness, I'll now also list potential downsides of me as TZ Coordinator. Most obviously, I haven't been on the TZ mailing list very long. I tend to pick things up quickly, but this is a defect in the experience I'd bring to the role. Secondly, I have a bit of a concern that my existing role as a consumer of the TZ database (via authorship of relevant Perl modules) might compromise objectivity in developing the API (loosely speaking) that the database provides to the world. (On the other hand, it certainly provides a useful perspective.) Thirdly, I'm of the firm opinion that timezones ought to be abolished, in favour of universal use of Universal Time. Here are links to relevant resources. Other mailing lists that I'm on: http://six.pairlist.net/pipermail/leapsecs/ (leap seconds) http://www.nntp.perl.org/group/perl.datetime/ (time data in Perl) http://www.nntp.perl.org/group/perl.perl5.porters/ (Perl core) Published Perl modules: https://metacpan.org/author/ZEFRAM Video of talk about time: http://www.presentingperl.org/lpw2011/why-time-is-difficult/ Miscellaneous other bits on my web page: http://www.fysh.org/~zefram/ -zefram

4 4

Encoding of workweek/weekend available?
by Andrew Paprocki March 17, 2012

March 17, 2012

Is there any public database similar to tzdata encoding workweek/weekend transitions over time? http://en.wikipedia.org/wiki/Workweek_and_weekend I am asking the folks on this list because the transitions sound eerily like DST transitions: "The coalition government formed on December 2011 issued a decree changing the weekend in Yemen. As of February 2012 the weekend in Yemen will be Friday–Saturday [instead of Thursday–Friday]." -Andrew

2 1

Eternal DST rules for Morocco from 2012 at last
by OvV_HN March 16, 2012

March 16, 2012

From: Dan Abitbol dabitbol at streamwide.com Thu Mar 15 10:21:07 UTC 2012 Hello Sorry to disturb again but as you know Morocco have new DST rules and first change is scheduled on 25 March 15, 2012-03-15 Do you plan to release 2012c that takes into account these new rules for Morocco soon ? .............. Reply: This is not going to be easy. If I understand the rules correctly, then the clocks will be put back during the month of Ramadan. Since the Islamic calendar wanders through the Gregorian calendar, in some years the full month of Ramadan falls in the summertime period, in some years Ramadan falls in the wintertime period and in other years the month of Ramadan partially overlaps with the DST period. I made a table for a couple of forthcoming years. Please note that this table is useless! The beginning of an Islamic month starts as soon as a religious authority declares that the crescent of the moon, immediately after an astronomical new moon, has been observed. This can't be predicted, but it can be approximated by some algorithm. For the table I have used the algorithm for the arithmetical Islamic calendar from Reingold in Calendrical Calculations 2. Note that an Islamic day actually starts at sunset of the day before the day mentioned. Table. (Best viewed with a monospace font). Column 1: Islamic year count. Column 2: the last Sunday of March in the Gregorian calendar. Column 3: the last Sunday of September in the Gregorian calendar. Column 4: the first day of the islamic month Ramadan in the Gregorian calendar. Column 5: the last day of the islamic month Ramadan in the Gregorian calendar. Islamic last Sun. last Sun. first of last of year March Sept. Ramadan Ramadan Gregorian Gregorian 1433 2012-3-25 2012-9-30 2012-7-20 2012-8-18 1434 2013-3-31 2013-9-29 2013-7-9 2013-8-7 1435 2014-3-30 2014-9-28 2014-6-29 2014-7-28 1436 2015-3-29 2015-9-27 2015-6-18 2015-7-17 1437 2016-3-27 2016-9-25 2016-6-7 2016-7-6 1438 2017-3-26 2017-9-24 2017-5-27 2017-6-25 1439 2018-3-25 2018-9-30 2018-5-16 2018-6-14 1440 2019-3-31 2019-9-29 2019-5-6 2019-6-4 1441 2020-3-29 2020-9-27 2020-4-24 2020-5-23 1442 2021-3-28 2021-9-26 2021-4-13 2021-5-12 1443 2022-3-27 2022-9-25 2022-4-3 2022-5-2 1444 2023-3-26 2023-9-24 2023-3-23 2023-4-21 1445 2024-3-31 2024-9-29 2024-3-11 2024-4-9 1446 2025-3-30 2025-9-28 2025-3-1 2025-3-30 1447 2026-3-29 2026-9-27 2026-2-18 2026-3-19 1448 2027-3-28 2027-9-26 2027-2-8 2027-3-9 1449 2028-3-26 2028-9-24 2028-1-28 2028-2-26 1450 2029-3-25 2029-9-30 2029-1-16 2029-2-14 1451 2030-3-31 2030-9-29 2030-1-6 2030-2-4 1452 2031-3-30 2031-9-28 2030-12-26 2031-1-24 1453 2032-3-28 2032-9-26 2031-12-15 2032-1-13 >From the table you can see that, for instance, in the Gregorian year 2012 the month Ramadan completely falls in the summertime period. In the Gregorian year 2026 the full month Ramadan falls outside the summertime period. In the Gregorian year 2023 Moroccan summertime starts effectively April 21 plus one (this is 1 Shawwal) (give or take 2 days; see above why), since Ramadan started just before the last Sunday of March. That's my interpretation, which can differ from the official one! Oscar van Vlijmen

1 0

Haiti on DST now
by Osko, Galatea March 15, 2012

March 15, 2012

Dear team, I'd like to subscribe to your DST changes notifications like the attached one. Thank you Galatea Osko Morgan Stanley | Enterprise Data Group Lechner Odon fasor 8 | Floor 06 Budapest, 1095 Phone: +36 1 881-3866 Galatea.Osko(a)morganstanley.com<mailto:Galatea.Osko@morganstanley.com> -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

1 0

Turkey may go on DST permanently
by Steffen Thorsen March 14, 2012

March 14, 2012

According to Turkish news media, there is a draft law, which will cancel the switch back from DST in October, effectively putting Turkey on UTC+3 all year. No final decision has been made yet. Some sources (in Turkish): http://www.hurriyet.com.tr/gundem/20112729.asp http://www.sabah.com.tr/Yasam/2012/03/14/surekli-yaz-saati-1-yil-sonra-basl… Our coverage: http://www.timeanddate.com/news/time/turkey-dst-2012.html Best regards, Steffen Thorsen - timeanddate.com

1 0

Re: [tz] TZ Coordinator candidate
by Doug Ewell March 12, 2012

March 12, 2012

Zefram <zefram at fysh dot org> wrote: > With ado's retirement now almost upon us, I'd like to volunteer for > the role of TZ Coordinator... I'm pretty sure I've never seen anything like this sort of self-campaigning, on any mailing list. Perhaps others who have been involved in more IETF lists have a different experience. Normally, a worthy candidate is nominated by others, and accepts the nomination with considerable humility. -- Doug Ewell | Thornton, Colorado, USA http://www.ewellic.org | @DougEwell

1 0

Haiti on DST now
by Steffen Thorsen March 11, 2012

March 11, 2012

According to several news sources, Haiti will observe DST this year, apparently using the same start and end date as USA/Canada. So this means they have already changed their time. (Sources in French): http://www.alterpresse.org/spip.php?article12510 http://radiovision2000haiti.net/home/?p=13253 Our coverage: http://www.timeanddate.com/news/time/haiti-dst-2012.html Best regards, Steffen Thorsen - timeanddate.com

2 1

Morocco will start DST on March 25, 2012
by Alexander Krivenyshev March 10, 2012

March 10, 2012

According to Infomédiaire web site from Morocco (infomediaire.ma), on March 9, 2012, (in French) Heure légale : Le Maroc adopte officiellement l'heure d'été http://www.infomediaire.ma/news/maroc/heure-l%C3%A9gale-le-maroc-adopte- officiellement-lheure-d%C3%A9t%C3%A9 Governing Council adopted draft decree, that Morocco DST starts on the last Sunday of March (March 25, 2012) and ends on last Sunday of September (September 30, 2012) except the month of Ramadan. or (brief) http://www.worldtimezone.com/dst_news/dst_news_morocco06.html Alexander Krivenyshev- WorldTimeZone.com http://www.worldtimezone.com

4 9

Cambios de Hora de Chile
by Glenn Eychaner March 6, 2012

March 6, 2012

From http://www.horaoficial.cl/cambio.html: > Inicio del horario de Invierno 2012: > De acuerdo al Decreto Supremo N° 225, del 27 de febrero de 2012 del Ministerio del Interior : > a.- En el continente y Antártica Chilena. > A las 24:00 horas del día Sábado 28 de Abril de 2012, se atrasa una hora pasando a ser las 23:00 del mismo día. > (Quedando como GMT/UTC - 04). > b.- En Isla de Pascua e Isla Salas y Gómez. > A las 22:00 horas del día Sábado 28 de Abril de 2012, se atrasa una hora pasando a ser las 21:00 del mismo día. > (Quedando como GMT/UTC - 06). > El horario de Invierno se mantendrá hasta el sábado primero de Septiembre de 2012. Start of Winter Time 2012: In accordance with Supreme Decree 225, 27 Feb 2012, from the Interior Ministry: a.- On the continent and in the Chilean Antarctic: At 24:00 on Saturday 28 April 2012, the hour will go back to 23:00 of the same day, moving to UTC-04. b.- On Easter Island and Isla Salas y Gómez: At 22:00 on Saturday 28 April 2012, the hour will go back to 21:00 of the same day, moving to UTC-06. Winter Time will remain until the first Saturday of September. -G. -- Glenn Eychaner (geychaner(a)lco.cl) Telescope Systems Programmer, Las Campanas Observatory

2 2

Australian Time Zone Abbreviations Discussion Review
by Shaun Bouckaert March 5, 2012

March 5, 2012

I started a discussion on this mailing list in November 2011 in regards to the incorrect time zone abbreviations used for Australian time zones. Initially there were several responses, the majority of which were positive to change, and yet the conversation seems to have died off. Recently published on this list was the IETF RFC 6557 "Procedures for Maintaining the Time Zone Database". The relevant section of that document to this discussion, Section 3 "Making Updates to the TZ Database" specifies at the bottom "To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgement and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was." Also, point 3.3 states "Changes to existing entries SHALL reflect the consensus on the ground in the region covered by that entry." There were several people involved in the discussion that took place: Myself (Shaun Bouckaert <shaun.bouckaert(a)gmail.com>) Edwin Groothuis <edwin(a)mavetju.org> Eric Ulevik <eulevik(a)gmail.com> Elliot Lear <lear(a)cisco.com> Greg Black <gjb(a)yaxom.com> I reside in Australia, however I am not aware of the nationality or residency of any of the other contributors. I will summarise my points then attempt to do so with the points made by others. It is not my intention to mislead and if my summaries of their contributions are inaccurate then I hope they will correct me. Their contributions to the original discussion are available to view. I originally started the discussion after finding the Australian Federal Government had a web page of information regarding time zones in Australia. This can be accessed at http://australia.gov.au/about-australia/our-country/time This lists the timezones as Australian Eastern Standard Time: UTC +10 hours abbreviated as AEST Australian Central Standard Time: UTC +9 ½ hours abbreviated as ACST Australian Western Standard Time: UTC +8 hours abbreviated as AWST Where daylight savings is concerned, NSW, ACT, Victoria and Tasmania move from AEST to Australian Eastern Daylight Time UTC +11 hours abbreviated as AEDT SA and Broken Hill in NSW move from ACST to Australian Central Daylight Time UTC +10 ½ hours abbreviated as ACDT After this initial posting Edwin replied with his support. Eric then replied stating that Time Zones are legislated at the state level, not the federal level, seeming to imply that only state law should matter. Considering the RFC specifically states that the time zone policy should be based on available sources to assess what the average person on the street would think, and the fact that state legislation doesn't specify an abbreviation, there's no reason that this federal government information, which accurately reflects what everyone I have discussed this matter with understands to be true, should be discounted. This was reenforced by Edwin who pointed out two ways forward, stay where we are based on the absence of any specification of abbreviations in state legislation and continue bickering on this issue or move forward with the clearly defined federal information that fixes ambiguity that exists on an international level with the existing abbreviations and hopefully stop the bickering. Elliot then put forward two points, the first in line with the now existing guidelines in regards to what people on the street think, and the second point being to taking caution to possible side effects that could be caused by changing this. He points out that we could be going from ambiguous labels to something that is also ambiguous, but is there a way of finding out if the AEST, ACST, etc. are ambiguous in any way? Considering the significance of EST and CST to North America, it certainly seems more significant to reduce the ambiguity there. Edwin then found several Australian organisations and reviewed what they use. Broadcasters: The ABC (National Broadcaster): AEST SBS: AEST Channel 10: Mostly AEST, some instances of EST News Organisations: Sydney Morning Herald: EST The Australian: AEST The Daily Telegraph: Both EST and AEST Government Organisations: The Australian Bureau of Meteorology: Uses both, but specifies using AEST in their submission guidelines. Appended to this list I can add the Queensland Department of Transport and Main Roads, which I found is using AEST in their website Terms of Service. I also pointed out at the time that many instances of the use of EST could easily be due to the current state of the TZ database and would likely be corrected to AEST (or other where appropriate) with the update to the TZ database. It was also pointed out that Australians would on large understand the use of the A prefixed abbreviations due to their widespread use, especially by major broadcasters and news media. Greg Black added that he received three emails from different Australian organisations that used ADST for a timezone that he would personally label AEDT. I do not see this being an argument against the change, but indeed an argument for. There is existing confusion, some of it due to the incorrect labels in the TZ database. The fact that the federal government has presented a source for this change means that there's significant grounds for using it as a correct version or standard. Of the 5 people mailing the list during this discussion, the most significant contributions were made by myself and Edwin, both of us in support of the change to the A prefix, which also seemed to be supported by Greg Black who said he would personally label the timezone that the ADST label had referred to as AEDT. I could find no arguments put forward that demonstrated any advantage of the current system over the proposed alternative besides maintaining the status quo. I respect the caution put towards unintended side effects, but where these are due to corrections on what is arguably wrong information, isn't it better to fix it sooner rather than later? Shaun Bouckaert

4 4

apparent-solar-time zone possible cleanup
by Zefram March 4, 2012

March 4, 2012

The apparent-solar-time zones seem to be misusing the "zzz" indicator, and they have poor boundary behaviour. The attached patch makes these changes that seem like a good idea to me: * abbreviation "LAT", for "Local Apparent Time", during the period where the zone provides LAT behaviour * additional apparent-time offset entry for Dec 31 of previous year, so that the ruleset provides LAT correctly for the first half of Jan 1 * range of validity of the LAT data defined strictly as starting and ending at Jan 1 00:00 UT * zone marked as disused outside the range of validity of the LAT data Also, thoughts on apparent solar time more generally: the existing solar?? files inconveniently can't be merged because the result would have more than 256 distinct offsets. However, if the resolution of the offsets were dropped from 5 s to 10 s, then there would be only 186 distinct offsets within the range of the equation of time, so we could have an apparent-time ruleset covering as many years as we're interested in. That could allow incorporating those rules into the regular Asia/Riyadh zone, rather than requiring these hacky separate zones. The apparent-time ruleset could also be formulaically generated at build time, rather than explicitly included in the source tarball. -zefram

1 1

IANA website error: 2012b -> 2012a
by Andrew Paprocki March 3, 2012

March 3, 2012

The IANA website currently says: "Time Zone Data v. 2012b (Released 2 March 2012) tzdata2012b.tar.gz (202kb)" Yet the href points to: http://www.iana.org/time-zones/repository/releases/tzdata2012a.tar.gz -Andrew

2 1

tabs in zone.tab
by Zefram March 2, 2012

March 2, 2012

My automatic repackager for CPAN has just barfed on the zone.tab in tzdata2012a. I should have checked the diff more carefully, I guess. The fault it finds is that the new America/Creston line has *two* tab characters between "America/Creston" and the region description. The comments at the top of the file include "Columns are separated by a single tab.". Previously the file adhered to the single tab rule, and I made my parser correspondingly strict. Obviously I'll manually intervene to get 2012a repackaged, but I think the file should be fixed for 2012b. -zefram

3 4

Reports of Leap Year problem...
by Robert Elz March 2, 2012

March 2, 2012

I cannot confirm any of this, except that the URL's included (the relevant ones for this list anyway) do point at web pages with content as claimed, but this seems like the kind of information that readers of this list would be amused by... kre

1 0

tzcode2012b & tzdata2012b available
by Robert Elz March 2, 2012

March 2, 2012

The files ftp://munnari.oz.au/pub/tzdata2012b.tar.gz ftp://munnari.oz.au/pub/tzcode2012b.tar.gz are now available. These reflect the changes circulated earlier today on the list. There is just one change to tzcode2012b (compared witth 2012a): the Makefile that was accidentally included with 2012a has been replaced with the version that should have been there, which is identical with the previous version (from tzcode2011i). For people upgrading directly from 2011i to 2012b, the changes in tzcode are just to the README and tz-art.htm and tz-link.htm and reflect changes to the mailing list address & subscription URLs, and the code distribution URLs and methods. tz-link.htm also has a link to DateTime::TimeZone::Tzfile added. There are just two changes in tzdata2012b compared with 2012a. Most significantly, summer time in Cuba has been delayed 3 weeks (now starts April 1 rather than March 11). Since Mar 11 (the old start date, as listed in 2012a) is just a little over a week away, this change is urgent. Less importantly, an excess tab in one of the changes in zone.tab in 2012a has been removed. Compared to the last long lived distribution (given tzdata2012a existed less than a day) which was tzdata2011n, the other major changes are: Chile 2011/2012 and 2012/2013 summer time date adjustments. Falkland Islands onto permanent summer time (we're assuming for the foreseeable future, though 2012 is all we're fairly certain of.) Armenia has abolished Summer Time. Tokelau jumped the International Date Line back last December (just the same as their near neighbour, Samoa). America/Creston is a new zone for a small area of British Columbia There will be a leapsecod 2012-06-30 23:59:60 UTC. Other minor changes are: Corrections to 1918 Canadian summer time end dates. Updated URL for UK timezone history (in comments) A few typos in Le Corre's list of free French place names (comments) Once again, crypto hashes of the distribution files, generated using NetBSD's pkgsrc digest program, are appended so you can verify the distribution files you fetch have not been corrupted. kre MD5 (tzcode2012b.tar.gz) = 6137322ffd36e1fd5128885be1c57008 RMD160 (tzcode2012b.tar.gz) = 25acce807c9e19d8294fe4dd8eac08fba9d796af SHA1 (tzcode2012b.tar.gz) = 7172f71a23fb6fe8f99099f810d05366ed5d7130 SHA512 (tzcode2012b.tar.gz) = 12b60b6b00db51651a85e4448c8795c8f0d0fbeeec66bec4e8613dff41fec3324a0b20f7d66183541a389eff0d2a93b3346a045a58a0d977739924f06d017fd3 TIGER (tzcode2012b.tar.gz) = a4378982416395d5d632270db4fb3c5c568ebf57b7130636 WHIRLPOOL (tzcode2012b.tar.gz) = 2a343f318b737a2b4e85f29416d25b07a04f3395a49c6e863a3bf4492b63de17545d30b0377ab4d1587fd0fc85ecf234fe2c45bff4bd2f0f97b33b82b3f2e3f0 MD5 (tzdata2012b.tar.gz) = 0615fd29def380a917e528433c820368 RMD160 (tzdata2012b.tar.gz) = b58bb8a633b664f5babed8a6681ecc25a039733d SHA1 (tzdata2012b.tar.gz) = cd7c43bf8ccf56d174a2b85d2da35e83fd8f1107 SHA512 (tzdata2012b.tar.gz) = 08f3f07e0abf75d278210fc9237344b6613b6b055bedf974b75437bfa153bdaf238135487acde38f352e55805b5bc9b3db93d9c08fdb3cfba68b3609c06445f9 TIGER (tzdata2012b.tar.gz) = 0b67a1f5408d8b6addd7c07df6e87fa9e54bb9102ae758fd WHIRLPOOL (tzdata2012b.tar.gz) = 530a6bcdf4fe4c92c478e709093c19fc2424c52a55756ea2e6cf66854f659bd67c6503e6235aa23348f5caeb5e92348a34d731334ca168a410feaa33f85533b0

1 0

Proposed update to the tz package files
by Robert Elz March 1, 2012

March 1, 2012

The combination of an accidental change to the Makefile in tzcode2012a that was never intended to be released, and the change of the summer time start date for Cuba, that we discovered just too late for 2012a (and the stray extra tab in zone.tab) has led me to the conclusion that we need 2012b very soon - like today... There will be both code & data files - the sole change in the code is to return the Makefile to the exact same version it had in 2011i, which was what it was supposed to be in 2012a. A diff of the data change from 2012a to (what will probably become) 2012b is appended. The only real change is to the start date for summer time in Cuba this year. The end date is not yet certain, so I'll just leave it as we have it (last Sun in Oct) and we'll see what happens in September or October (probably). Since there is no discernable pattern to the start dates, I'm also proposing leaving that for 2013 as we had assumed it would be for 2012 (second Sunday in March). It has been that more years recently than anything else (just not last year, or this year, but they've not been the same either.) The excess tab from the zone.tab file is also gone. For anyone considering upgrading their system to 2012a, who hasn't already done it, I'd advise waiting on 2012b, it is not going to be a long wait. kre --- northamerica 2012/03/01 11:22:55 1.5 +++ northamerica 2012/03/01 20:46:07 @@ -1,5 +1,5 @@ # <pre> -# @(#)northamerica 8.52 +# @(#)northamerica 8.53 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. @@ -2820,8 +2820,9 @@ Rule Cuba 2009 2010 - Mar Sun>=8 0:00s 1:00 D Rule Cuba 2011 only - Mar Sun>=15 0:00s 1:00 D Rule Cuba 2011 only - Nov 13 0:00s 0 S -Rule Cuba 2012 max - Mar Sun>=8 0:00s 1:00 D +Rule Cuba 2012 only - Apr 1 0:00s 1:00 D Rule Cuba 2012 max - Oct lastSun 0:00s 0 S +Rule Cuba 2013 max - Mar Sun>=8 0:00s 1:00 D # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Havana -5:29:28 - LMT 1890 --- zone.tab 2012/03/01 11:26:34 1.6 +++ zone.tab 2012/03/01 15:30:24 @@ -131,7 +131,7 @@ CA +690650-1050310 America/Cambridge_Bay Mountain Time - west Nunavut CA +6227-11421 America/Yellowknife Mountain Time - central Northwest Territories CA +682059-1334300 America/Inuvik Mountain Time - west Northwest Territories -CA +4906-11631 America/Creston Mountain Standard Time - Creston, British Columbia +CA +4906-11631 America/Creston Mountain Standard Time - Creston, British Columbia CA +5946-12014 America/Dawson_Creek Mountain Standard Time - Dawson Creek & Fort Saint John, British Columbia CA +4916-12307 America/Vancouver Pacific Time - west British Columbia CA +6043-13503 America/Whitehorse Pacific Time - south Yukon

1 0

Cuba delays DST to April
by Steffen Thorsen March 1, 2012

March 1, 2012

According to Radio Reloj, Cuba will start DST on Midnight between March 31 and April 1. Radio Reloj has the following info (Spanish): http://www.radioreloj.cu/index.php/noticias-radio-reloj/71-miscelaneas/7529… Our info on it: http://www.timeanddate.com/news/time/cuba-starts-dst-2012.html Best regards, Steffen Thorsen - timeanddate.com

2 1

tzcode2012a & tzdata2102a released.
by Robert Elz March 1, 2012

March 1, 2012

The files ftp://munnari.oz.au/pub/tzdata2012a.tar.gz ftp://munnari.oz.au/pub/tzcode2012a.tar.gz are now available. These reflect the changes circulated earlier this week, as corrected based upon reports received, and summarised below. The changes in tzcode2012a (compared to the previous version, 2011i) are entirely to the README and tz-art.htm and tz-link.htm files, if none of those concern you, you can ignore the code update. The changes reflect the changed addresses for the mailing list and the code and data distribution points & methods (and a link to DateTime::TimeZone::Tzfile has been added to tz-link.htm). In tzdata2012a (compared to the previous release, which was 2011n) the major changes are: Chile 2011/2012 and 2012/2013 summer time date adjustments. Falkland Islands onto permanent summer time (we're assuming for the foreseeable future, though 2012 is all we're fairly certain of.) Armenia has abolished Summer Time. Tokelau jumped the International Date Line back last December (just the same as their near neighbour, Samoa). America/Creston is a new zone for a small area of British Columbia There will be a leapsecod 2012-06-30 23:59:60 UTC. A few more minor changes are also included: Changes to Canadian 1918 summer time end dates (so it occurred on a Sunday, rather than Thursday, which is more likely correct.) A new URL (in the comments in the europe zone file) to the article describing the history of timezones in the UK (this should probably be promoted to a link in tzlink.htm or something, but that hasn't happened yet.) A couple of typo corrections to the list of French place names reported by Henri Le Corre that define the upper limit of the free zone where (as I understand it) German rules were not applies during (a part of) WWII. These are based on the rendition supplied by John Halloran, and unless I botched it, should make what we have be a correct copy of the source, as nearly as is possible in strict ASCII (the accent marks are missing...) I know I said we would hold off on this until the next version, but with the data being available, and the corrections needed so simple, I thought I could include it in this version. Now we can discuss what how we should represent the data with perhaps more modern (or better ascii versions of) place names in the next version, but at least now we're working from a common (external) base source. I still have not implementewd (even really seriously investigated) the procedures necessary to generate signed files, so once again I am appending to this message the results of several (crypto strength) hash functions applied to the two files (and this time, all this has been prepared on my laptop at a time when it isn't connected to any network at all, so there's an even higher level of assurance than normal that these hashes really do represent the data I intend to distribute.) The "digest" program from NetBSD's pkgsrc (which can be installed on many different OSs) was used to generate these values (but anything running any of the same algorithms should produce the same results.) Finally, it is my hope (though without intending to apply any pressure) that the next release will be back under the coordination of Arthur David Olson (I'll continue if he's unwilling, and Paul Eggert doesn't want to take over instead, but I'd much prefer to see ado back in control, for as long as he wants to continue.) Thanks for all the assistance from everyone that I've received over the few months I've been doing this, this is truly one of the nicest and most satisfying of the network communities in which to participate. kre MD5 (tzcode2012a.tar.gz) = a72bb8c29893ee3bfd1101aca29d4064 MD5 (tzdata2012a.tar.gz) = cc43867f4768e5c2e8315d9b3cac62ed RMD160 (tzcode2012a.tar.gz) = b498355392e7e141e12fc4ca3592cfec6e96ef00 RMD160 (tzdata2012a.tar.gz) = b95722a2d42744bb217e11ace7b5bc7195f86d77 SHA1 (tzcode2012a.tar.gz) = 80e0c9efb067950f34826d0708ff61e72e019da5 SHA1 (tzdata2012a.tar.gz) = 5bd828d0845937da92c0518060a4aa8fbad81f8d SHA512 (tzcode2012a.tar.gz) = c37d95081a1097ba46d1887ef13bf112216bc45f21542bf559744f329602e109c3a9a7a7705ed41432049ad3905f87a747ddbc6f7c11470fcf44fc5bf946c9e3 SHA512 (tzdata2012a.tar.gz) = dff197b7ae7a204fa2c716d27ad83c0f29fba3bdede0059d0507ad3f4117849c90e578df5bba62c397e1709bce1c26382a61b0ea9c8face671e7228dbf5b7bab TIGER (tzcode2012a.tar.gz) = 3f38fc0884f3eef800289a9e6cd9ee69b0405f75447319fc TIGER (tzdata2012a.tar.gz) = d0609c3f36e735ab5708f473336f66edb33f68d58333b9dc WHIRLPOOL (tzcode2012a.tar.gz) = 5a98d5ecb0956eba9f52403ea58125933998f3d1f402fba5b04815b5c2d861e9c010df38258a8f479c8a26a7d301c5d45e63a5a0586e24dcdd97007051e0ca5b WHIRLPOOL (tzdata2012a.tar.gz) = 4c3e7e372d708baf5cf15ece01c31f38880e50fbf402ef346d0cd27f4203282862660322a76efb1144b84ff08c86407e714fc1d858e1c7ce22f7cbb10923fb52

3 3