- tz - lists.iana.org

Normatively citing the TZ database
by Jonathan Lennox Sept. 1, 2003

Sept. 1, 2003

I'm writing a specification for a language (the Call Processing Language, for user-specific routing of telephone calls) which needs to support the users' time zones for time-of-day routing. (The current draft is available at <http://www.cs.columbia.edu/~lennox/draft-ietf-iptel-cpl-07.txt> for those who are interested.) The draft includes the following paragraph: While "tzid" labels that do not begin with a forward slash are locally defined, it is RECOMMENDED that servers support at least the naming scheme used by Olson Time Zone database [9]. Examples of timezone databases that use the Olson scheme are the zoneinfo files on most Unix-like systems, and the standard Java TimeZone class. Currently reference [9] refers to <http://www.twinsun.com/tz/tz-link.htm>, which is tz-link.htm from tzcode. I've been asked, though, whether this is the best way to make reference to the TZ database; and I have to concede that it might not be, since it's dependent on Twinsun's continuing support. What would mailing list members suggest is the best (most canonical, most stable) way of referencing the TZ database? -- Jonathan Lennox lennox at cs dot columbia dot edu

4 5

FW: a correction to the tz database
by Olson, Arthur David (NIH/NCI) Aug. 29, 2003

Aug. 29, 2003

Härmel Nestra is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Härmel Nestra [mailto:nestra@math.ut.ee] Sent: Wednesday, July 30, 2003 7:18 AM To: tz(a)lecserver.nci.nih.gov Subject: a correction to the tz database Hello, I would like to inform you that your database contains incorrect information about the time observed by the Baltic states Estonia and Latvia. According to your database, we are observing standard time, but actually we are observing daylight saving time currently, so our time is 3 hours in advance w.r.t UTC. The DST start and end dates are the same as in EU. I don't know about Lithuania but, according to http://www.worldtimeserver.com/ , it is also observing DST this year. Cheers, HN

2 1

Re: epochs and the gregorian reform
by Gilbert C Healton Aug. 29, 2003

Aug. 29, 2003

Then there is the way standards such as ISO-8601 handle the problem... they ignore it, running the current calendar back, as if there was no calendar correction, into dim history. Such are called "proleptic" calendar, which I view as an artifical calendar not good for any dates, but an agreed upon way to handle the problem. People receiving such dates convert them to the local dates, as appropriate. I don't really LIKE this solution, however getting everyone to agree on what calendars changed when is very difficult. Especially since countries, such as the United States, changed on different dates depending on what country controlled the land at any particular moment. A real can of worms. --------------------------------------------------------------------- ghealton(a)exit109.com http://www.exit109.com/~ghealton/ ---------------------------------------------------------------------- Computers are like air conditioners: they don't work well when Windows are left open On Tue, 29 Jul 2003, Andrew Brown wrote: >>> it struck me that the tz data base would not be an unreasonable place >>> to store the "local" date at which the gregorian reform took place >> >>I privately started a little list to do that, but gave it up for lack >>of time. I found it hard to get authoritative data. It is hard to >>get reliable information about transitions that occurred that long >>ago. > >i suppose something that was somewhat accurate (ie, culled from a few >sources) as a starting point, and then was subject to readjustment (as >necessary) wouldn't do? doesn't all the tz data work like that? :) > >>> italy adopted the reform (1582/10/05), >> >>That's true for most of Italy, but Toke Norby writes that Florence and >>Pisa didn't switch until 1749-12-21 Julian (1750-01-01 Gregorian). > > > >>> or japan (1872/12/20). >> >>You're giving a Julian date, but didn't Japan use a lunar calendar >>previously? And I've seen different sources about when the actual >>change occurred, ranging from 1873-01-01 Gregorian (your date) through >>1919-01-01. Possibly they switched for some purposes at first but not >>others, which would mean there's no single date of switch. > >actually, i was giving the date of the first skipped day on the julian >calendar (so 1873/01/01 would be the first day actually occurring on >the gregorian calendar) . since japan is "oriental", i can imagine >them being subject to the footnote in calendrical calculations that >notes that they don't use the gregorian calendar, but a reformed >julian calendar. they're approximately the same...until 2800. > >>> (modulo the various cantons in switzerland and the parts of germany >>> that were protestant in the 16th century). >> >>It's worse than that. In some of those places the date depended on >>who you were talking to. Even in the same town, part of the >>population would use Julian and the other part Gregorian. > >yes, it might be difficult to decide on the granularity to use. > >>Also, once you go back that far, you should also address the issue of >>when the year started. For example, much of Europe started the >>calendar year on March 25 from the 12th through the 16th centuries. >>And some of Europe started the calendar year on Christmas Day. > >yes, well, i was going to sort of ignore that, too. fwiw, i was also >briefly beholden of the notion that the timezone database might hold >"epoch" information, meaning that "second zero corresponds to calendar >date yyyy/mm/dd" so that implementing a "hebrew" timezone (with the >corresponding epoch) would be possible. then i read up on the >structure of the hebrew calendar and decided to leave that to people >who "need to know". if i "need to know", i'm sure i could find >today's hebrew date much more easily than i could code it in an >evening. > >>Anyway, if I haven't discouraged you from doing the job right (:-) >>here are some references that you may find of interest: >> >><http://www.norbyhus.dk/calendar.html> >><http://www.tondering.dk/claus/calendar.html> >>Two good sources for general calendrical information. > >got that from van vlijmen, but thanks. > >><http://www.genfair.com/dates.htm> >>Explains calendrical issues for western Europe particularly well. >>Oriented towards genealogists. > >i think i've found that one before. note, of course, that this is but >one page, and the information is entirely duplicated in other >"sources". > >><http://www.calendarists.com> >>By far the highest-quality source of information for computerized calendars. >>However, they don't worry about transition dates much. > >ah. more good work from the calendrical calculations people. very >nice. > >as a footnote, the shift from julian to gregorian calendaring (or >something along those lines) is, imho, rather germaine to the tz data, >since, for example: > > % env TZ=Europe/Moscow date -r -1645700000 +"%B %e, %Y" > November 7, 1917 > >as a sample date, is "wrong", because the localtime() routine ignores >the gregorian reform. :) > >-- >|-----< "CODE WARRIOR" >-----| >codewarrior(a)daemon.org * "ah! i see you have the internet >twofsonet(a)graffiti.com (Andrew Brown) that goes *ping*!" >werdna(a)squooshy.com * "information is power -- share the wealth." >

3 2

RE: New code CS for Serbia and Montenegro
by Misha Wolf Aug. 14, 2003

Aug. 14, 2003

Note that until 1993 this ("CS") was the code for Czechoslovakia. Misha -----Original Message----- From: Jesper Nørgaard [mailto:jnorgard@prodigy.net.mx] Sent: 14 August 2003 05:53 To: 'TZ mailing list' Subject: New code CS for Serbia and Montenegro According to http://www.iso.org/iso/en/prods-services/iso3166ma/01whats-new/2003-07-23_s… the country codes for Serbia and Montenegro (former Yugoslavia), has finally been determined. ISO 2-letter code "YU" is changed to "CS", and ISO 3-letter code "YUG" is changed to "SCG". This happened 23rd of July 2003. I was informed about this by Andreas Moser from Germany. This will affect the iso3166.tab file and the zone.tab files, if not more places in the TZ database. Regards, Jesper Nørgaard Welen Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (5) 58-04-20-04 ext. 1374 Fax: +52 (5) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the free program World Time Explorer, I made: http://www.cimmyt.org/timezone/index.htm -------------------------------------------------------------- -- Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

1 0

New code CS for Serbia and Montenegro
by Jesper Nørgaard Aug. 14, 2003

Aug. 14, 2003

According to http://www.iso.org/iso/en/prods-services/iso3166ma/01whats-new/2003-07-23_s… the country codes for Serbia and Montenegro (former Yugoslavia), has finally been determined. ISO 2-letter code "YU" is changed to "CS", and ISO 3-letter code "YUG" is changed to "SCG". This happened 23rd of July 2003. I was informed about this by Andreas Moser from Germany. This will affect the iso3166.tab file and the zone.tab files, if not more places in the TZ database. Regards, Jesper Nørgaard Welen Jesper Nørgaard Welen Email: jnorgard(a)Prodigy.Net.mx Project Leader (Líder de Proyecto) Software CIMMYT - Centro Internacional de Mejoramiento de Maíz y Trigo Dirección: CIMMYT Int. c/o Jesper Nørgaard Km. 45, Carretera México-Veracruz El Batán Texcoco, Edo. de México CP 56130 MEXICO Tel.: +52 (5) 58-04-20-04 ext. 1374 Fax: +52 (5) 58-04-75-58 Tel. Casa: 53-10-05-95 ó 53-10-97-78 Download the free program World Time Explorer, I made: http://www.cimmyt.org/timezone/index.htm

1 0

New e-mail for IERS/PC
by iers＠hpopa.obspm.fr Aug. 4, 2003

Aug. 4, 2003

Dear colleagues, Consequently to a new management of mailing procedures, the e-mail iers(a)obspm.fr is deleted. The new address is services.iers(a)obspm.fr Meanwhile the e-mail iers(a)hpopa.obspm.fr stays valid. Teddy Carlucci IERS/PC (Bulletin C)

1 0

utility creating a dst cache
by Chuck Soper Aug. 1, 2003

Aug. 1, 2003

Hello, I'm writing a utility that uses the tz database. One of the features is to quickly (via a cache saved to disk) display daylight saving times for a given year and tz location. If the tz package is updated then I will need to re-create my dst cache. Is there a way to programmatically determine if the tz package has been updated since the last time I ran my utility? Is there a way to determine if a specific zoneinfo file has been updated? Thanks, Chuck

2 1

Antw: utility creating a dst cache
by WHarms＠bfs.de Aug. 1, 2003

Aug. 1, 2003

hi chuck, the modification time is store in the filesystem, for the more paranoid you can use dnotify() an become informed when ever the dir is used. fast way is to store a checksum e.g. md5 and compare after a notify event. walter - - - - - - - - - - - - - - Originalnachricht - - - - - - - - - - - - - - Von: Chuck Soper <chucks(a)lmi.net> Betreff: utility creating a dst cache Datum: 01.08.03 21:43 Hello, I'm writing a utility that uses the tz database. One of the features is to quickly (via a cache saved to disk) display daylight saving times for a given year and tz location. If the tz package is updated then I will need to re-create my dst cache. Is there a way to programmatically determine if the tz package has been updated since the last time I ran my utility? Is there a way to determine if a specific zoneinfo file has been updated? Thanks, Chuck

1 0

RE: epochs and the Gregorian reform
by Infoman July 30, 2003

July 30, 2003

Adding the date of adoption of the Gregorian reform for a given region to the compiled time zone is of interest to the social studies (history, economics, political science) as well as geographers, environmentalists, trade and shipping historians, genealogists, etc.. The results could/should be packaged as a easily reference and useful document for users of this nature. They in turn might be able to provide inputs also. regards - Jake Knoppers -----Original Message----- From: Andrew Brown [mailto:atatat@atatdot.net] Sent: Tuesday, July 29, 2003 8:25 PM To: Oscar van Vlijmen Cc: TZ-list Subject: Re: epochs and the gregorian reform >> while it's not strictly related, i've often found myself wondering if >> adding the date of the adoption of the gregorian reform for a given >> region to the compiled zone file might be of interest. > >One of the places where information about the Julian -> Gregorian transition >dates are kept is The Calendar FAQ: >http://www.tondering.dk/ that's really neat, and i'll bookmark it. that said, informationally, it's approximately the same as the calendrical calculations book. while useful to know about, it's not really sufficient programmatically, since the data is still in "text" form and not easily accessible to your program. :) thanks again for the link. -- |-----< "CODE WARRIOR" >-----| codewarrior(a)daemon.org * "ah! i see you have the internet twofsonet(a)graffiti.com (Andrew Brown) that goes *ping*!" werdna(a)squooshy.com * "information is power -- share the wealth."

1 0

a correction to the tz database
by Härmel Nestra July 30, 2003

July 30, 2003

Hello, I would like to inform you that your database contains incorrect information about the time observed by the Baltic states Estonia and Latvia. According to your database, we are observing standard time, but actually we are observing daylight saving time currently, so our time is 3 hours in advance w.r.t UTC. The DST start and end dates are the same as in EU. I don't know about Lithuania but, according to http://www.worldtimeserver.com/ , it is also observing DST this year. Cheers, HN

1 0

FW: epochs and the gregorian reform
by Olson, Arthur David (NIH/NCI) July 29, 2003

July 29, 2003

Andrew Brown is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Andrew Brown [mailto:atatat@atatdot.net] Sent: Tuesday, July 29, 2003 12:20 AM To: tz(a)lecserver.nci.nih.gov Subject: epochs and the gregorian reform while it's not strictly related, i've often found myself wondering if adding the date of the adoption of the gregorian reform for a given region to the compiled zone file might be of interest. i recently worked over cal(1) in netbsd to remove the places where 1752/09/03 was "hard-coded" as the date of the adoption of the reform, adding in it's place a nice list of dates for various places, and demoted 1752/09/03 to a mere default. as a result, i can ask cal to show me the calendar at the time that italy adopted the reform (1582/10/05), or japan (1872/12/20). note that i did not attempt to handle things like sweden from 1700-1712. it struck me that the tz data base would not be an unreasonable place to store the "local" date at which the gregorian reform took place (modulo the various cantons in switzerland and the parts of germany that were protestant in the 16th century). crazy? -- |-----< "CODE WARRIOR" >-----| codewarrior(a)daemon.org * "ah! i see you have the internet twofsonet(a)graffiti.com (Andrew Brown) that goes *ping*!" werdna(a)squooshy.com * "information is power -- share the wealth."

2 1

epochs and the gregorian reform
by Andrew Brown July 29, 2003

July 29, 2003

while it's not strictly related, i've often found myself wondering if adding the date of the adoption of the gregorian reform for a given region to the compiled zone file might be of interest. i recently worked over cal(1) in netbsd to remove the places where 1752/09/03 was "hard-coded" as the date of the adoption of the reform, adding in it's place a nice list of dates for various places, and demoted 1752/09/03 to a mere default. as a result, i can ask cal to show me the calendar at the time that italy adopted the reform (1582/10/05), or japan (1872/12/20). note that i did not attempt to handle things like sweden from 1700-1712. it struck me that the tz data base would not be an unreasonable place to store the "local" date at which the gregorian reform took place (modulo the various cantons in switzerland and the parts of germany that were protestant in the 16th century). crazy? -- |-----< "CODE WARRIOR" >-----| codewarrior(a)daemon.org * "ah! i see you have the internet twofsonet(a)graffiti.com (Andrew Brown) that goes *ping*!" werdna(a)squooshy.com * "information is power -- share the wealth."

1 0

tzdata version - Re: My confusion with Asia/Aqtau
by Robbin Kawabata July 28, 2003

July 28, 2003

> the statement "I hope that I'm using version 2003a." > indicates that we also need to include the tz version where the change was > added. How about adding a version file in the tzdata database, say _tz_version.txt, that contains something like: :::::::::: _tz_version.txt :::::::::: tzdata 2003a _tz_version.txt could be a text file that is part of the tzdata source tar file. zic could install it to the /usr/lib/zoneinfo/ (or wherever) directory. Then zdump -V (new option) could read the _tz_version.txt file, and print the version as "2003a". An inconsistency is that the files in the /usr/lib/zoneinfo/ directory are zoneinfo files, while _tz_version.txt is not. A user (or script) could try to set TZ=_tz_version.txt even though it is not a valid zoneinfo file. It could help to create a new src directory under zoneinfo, that would contain source files.

1 0

Re: DST in Canada through early 1916
by Paul Eggert July 28, 2003

July 28, 2003

Mark, the interesting news in your extracts from the Toronto Star is that Port Arthur, Ontario (now part of Thunder Bay) was observing DST in 1912. This info isn't in the tz database now. This led me to track down a copy of the 19th edition of William Willett's pamphlet "The Waste of Daylight" (dated March 1914). Willett mentions Moose Jaw, and also mentions Port Arthur and Fort William as observing DST two years before Moose Jaw did. (See ref. below.) Since Moose Jaw observed DST in 1912 (according to the Toronto Star), the Thunder Bay region must have observed it starting in 1910. This is a new record for the earliest recorded observance of daylight-saving time. Thanks very much for bringing this to my attention; I'll include a new tz Rule (called "Thunder") in my next proposed update. Unfortunately we don't know when the Thunder Bay region stopped observing DST, or what DST rules they used. For lack of better info, I'll guess they observed DST through 1917 (since Canada had uniform rules in 1918), and that they used Willett's proposal, namely third Sunday in April at 02:00 to third Sunday in September at 03:00. I imagine the only way to check this guess would be to consult the newspapers printed near Thunder Bay at the time. Probably the best place to do that would be the Lakehead University Library. If anyone on the tz list can check that library I'd appreciate any news about this. Reference: <http://www.pettswoodvillage.co.uk/Daylight_Savings_William_Willett.pdf> I just love the Internet for this stuff! Several years ago, I couldn't find a copy of this pamphlet in the University of California research libraries; now it's on the net in PDF form.

1 0

DST in Canada through early 1916
by Paul Eggert July 27, 2003

July 27, 2003

[Forwarded with permission from Mark Brader.] Date: Sat, 26 Jul 2003 19:18:32 -0400 (EDT) From: msb(a)vex.net (Mark Brader) I spent some time at the Toronto Reference Library today. On May 31 I wrote (to Paul and Tom): > The library now has access to a computerized archive of the Toronto > Star back to its founding; I may do a search on DST sometime, but as > I said, I was there for other reasons today, and I didn't want to take > any more time on this. The archive, called "Pages of the Past", contains a scanned image of every page; you can request a particular date and page, or locate pages of possible interest by full-text searches. The search has four options: "exact phrase", "any of these words", "all of these words", "boolean". However, there doesn't seem to be a way to ask for "any of these exact phrases"; at least, the obvious things to try didn't work. Although any library user can access the archive, it's not available on the WWW; you have to go to the library, and access to their computers may be limited if other people are waiting. In this case other people weren't waiting and I was able to get a couple of hours continuously. But again I was there for another reason -- subway history is more interesting than time zone history, after all -- and I didn't want to spend all my time doing this. I chose to search on the exact phrase "daylight saving" (rather than "daylight savings" or "summer time"), and to search forward from the founding of the paper in 1894 until I got to some interesting stuff. Everything below is in my own words. Dates in parentheses are dates of the newspaper articles rather than the events. The very first hit was on (1908-07-09), a one-paragraph item to the effect that New York financiers were alarmed at the popularity of a DST bill in England. Tea time at 5:00, they said, already subtracts too much from business hours. On 1909-03-12 (-13) E.N. Lewis, MP, introduced a bill calling for DST on a national basis for a 2-month period. This was not taken very seriously by the parliamentarians, but it survived to a second reading on 1909-03-29 (-30), when it was referred to committee. On (1914-01-15) it was reported that Lewis was again preparing to introduce his bill -- this time the Star said it called for the clocks to be turned BACK an hour during the summer months! The first actual adoption of DST in Canada was at the municipal level. As the Star put it (1912-06-07), "While people elsewhere have long been talking of legislation to save daylight, the city of Moose Jaw [Saskatchewan] has acted on its own hook." DST in Moose Jaw began on Saturday, 1912-06-01 (no time mentioned: presumably late evening, as below), and would run until "the end of the summer". The discrepancy between municipal time and railroad time was noted. Orillia, Ontario, adopted DST effective Saturday, 1912-06-22, 22:00; the article mentions that Port Arthur (now part of Thunder Bay, Ontario) as well as Moose Jaw have already done so. In Orillia DST was to run until Saturday, 1912-08-31 (no time mentioned), but it was met with considerable hostility from certain segments of the public, and was revoked after only two weeks -- I copied it as Saturday, 1912-07-07, 22:00, but presumably that should be -07-06. (1912-06-19, -07-12; also letters earlier in June). Kenora, Ontario, was to abandon DST on 1914-06-01 (-05-21). Winnipeg, Manitoba, was noted on (1916-02-29) as having adopted DST. On (1916-05-04) it was noted that there was now little doubt that Britain would follow Holland's example and adopt DST. There were many more hits in 1916, and at this point I stopped searching. Feel free to forward this to tz, or better yet, just the interesting bits; or not to, as you wish. -- Mark Brader, Toronto, msb(a)vex.net "No, no, Oscar, you forget. When you and I are together, we never talk about anything except me." --James MacNeill Whistler "It is true, Jimmy, we were talking about you, but I was thinking of myself." --Oscar Wilde

1 0

FW: better overflow check
by Olson, Arthur David (NIH/NCI) July 25, 2003

July 25, 2003

Ulrich Drepper is on the time zone mailing list, but at a different address than the one below. Direct replies carefully. --ado -----Original Message----- From: Ulrich Drepper [mailto:drepper@redhat.com] Sent: Thursday, July 24, 2003 8:53 PM To: tz(a)lecserver.nci.nih.gov Subject: better overflow check -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The code at the end of zic.c:rpytime has the comment Cheap overflow check. Indeed, cheap. And unfortunately insufficient. If the code is executed on a machine with 64 bit time_t the result differs from that you get on a machine with 32 bit time_t. The following patch does a better job. - --- timezone/zic.c 6 Apr 2002 03:39:57 -0000 1.14 +++ timezone/zic.c 25 Jul 2003 00:48:48 -0000 1.15 @@ -2152,12 +2152,13 @@ } if (dayoff < 0 && !TYPE_SIGNED(time_t)) return min_time; + if (dayoff < min_time / SECSPERDAY) + return min_time; + if (dayoff > max_time / SECSPERDAY) + return max_time; t = (time_t) dayoff * SECSPERDAY; - - /* - - ** Cheap overflow check. - - */ - - if (t / SECSPERDAY != dayoff) - - return (dayoff > 0) ? max_time : min_time; + if (t > 0 && max_time - t < rp->r_tod) + return max_time; return tadd(t, rp->r_tod); } - -- - --------------. ,-. 444 Castro Street Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA Red Hat `--' drepper at redhat.com `--------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/IH8K2ijCOnn/RHQRAgSOAKCGEBJ9z2ToBRnKeXzLgPDMP4m1EgCfSos7 JcgAEplXNFZy95IqU50gsFM= =mZY1 -----END PGP SIGNATURE-----

2 1

better overflow check
by Ulrich Drepper July 25, 2003

July 25, 2003

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The code at the end of zic.c:rpytime has the comment Cheap overflow check. Indeed, cheap. And unfortunately insufficient. If the code is executed on a machine with 64 bit time_t the result differs from that you get on a machine with 32 bit time_t. The following patch does a better job. - --- timezone/zic.c 6 Apr 2002 03:39:57 -0000 1.14 +++ timezone/zic.c 25 Jul 2003 00:48:48 -0000 1.15 @@ -2152,12 +2152,13 @@ } if (dayoff < 0 && !TYPE_SIGNED(time_t)) return min_time; + if (dayoff < min_time / SECSPERDAY) + return min_time; + if (dayoff > max_time / SECSPERDAY) + return max_time; t = (time_t) dayoff * SECSPERDAY; - - /* - - ** Cheap overflow check. - - */ - - if (t / SECSPERDAY != dayoff) - - return (dayoff > 0) ? max_time : min_time; + if (t > 0 && max_time - t < rp->r_tod) + return max_time; return tadd(t, rp->r_tod); } - -- - --------------. ,-. 444 Castro Street Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA Red Hat `--' drepper at redhat.com `--------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/IH8K2ijCOnn/RHQRAgSOAKCGEBJ9z2ToBRnKeXzLgPDMP4m1EgCfSos7 JcgAEplXNFZy95IqU50gsFM= =mZY1 -----END PGP SIGNATURE-----

1 0

RE: My confusion with Asia/Aqtau
by Olson, Arthur David (NIH/NCI) July 22, 2003

July 22, 2003

Dave Rolsky's interpretation of what the "asia" file *says* is happening is correct, as witness output from "zdump -v Asia/Aqtau | grep 1995": Asia/Aqtau Sat Mar 25 20:59:59 1995 UTC = Sun Mar 26 01:59:59 1995 AQTT isdst=0 Asia/Aqtau Sat Mar 25 21:00:00 1995 UTC = Sun Mar 26 03:00:00 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 17:59:59 1995 UTC = Sat Sep 23 23:59:59 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 18:00:00 1995 UTC = Sat Sep 23 23:00:00 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 21:59:59 1995 UTC = Sun Sep 24 02:59:59 1995 AQTST isdst=1 Asia/Aqtau Sat Sep 23 22:00:00 1995 UTC = Sun Sep 24 02:00:00 1995 AQTT isdst=0 (Recall that for each time change zic produces a "before" and "after" line; six lines above means there were three changes in 1995). I don't know *really* happened in Asia/Aqtau in 1995; if there was indeed just one change to clocks, the "1995 Sep lastSun" line needs tweaking. --ado -----Original Message----- From: Dave Rolsky [mailto:autarch@urth.org] Sent: Friday, July 18, 2003 1:34 AM To: tz(a)lecserver.nci.nih.gov Subject: My confusion with Asia/Aqtau I'm trying to implement a parse/code generator based on the Olson DB _text_ files (not binary). I think I've got it mostly working, but there's some strange edge cases. One of them involves Asia/Aqtau, and I'm trying to figure out if I'm _really_ understanding what the file indicates. The observances for this zone include the following: 5:00 RussiaAsia AQT%sT 1995 Sep lastSun # Aqtau Time 4:00 RussiaAsia AQT%sT The RussiaAsia rules include the following rules which apply to those observances: Rule RussiaAsia 1993 max - Mar lastSun 2:00s 1:00 S Rule RussiaAsia 1993 1995 - Sep lastSun 2:00s 0 - Rule RussiaAsia 1996 max - Oct lastSun 2:00s 0 - By my reading, this indicates the following transitions: * On Sep 24, 1995 at 00:00:00 _local_ time, the offset from UTC changes from 05:00 to 04:00. However, the DST rule is still in effect, so the total offset goes from 06:00 to 05:00. * On Sep 24, 1995 at 01:00:00 local time (2:00s == 1:00 wall when DST is in effect), the rule changes so that DST is no longer in effect, and the cumulative offset goes from 05:00 to 04:00. Is this _really_ correct? It seems awfully strange to have an observance change so close to a DST change. And if cases like these are possible, it's really going to complicate my code. But if it is correct, I do want to get it right in my code. OTOH, if it's wrong, and such things don't happen, I'd be just as happy to leave me code as is ;) -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/

6 7

More strangenes in zdump: no LMT
by Dave Rolsky July 22, 2003

July 22, 2003

The data for Africa/Abidjan contains this: Zone Africa/Abidjan -0:16:08 - LMT 1912 0:00 - GMT But zdump gives me this: Africa/Abidjan Mon Jan 1 00:16:07 1912 UTC = Sun Dec 31 23:59:59 1911 GMT isdst=0 gmtoff=-968 Africa/Abidjan Mon Jan 1 00:16:08 1912 UTC = Mon Jan 1 00:16:08 1912 GMT isdst=0 gmtoff=0 Africa/Abidjan Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 03:14:07 2038 GMT isdst=0 gmtoff=0 Africa/Abidjan Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 03:14:07 2038 GMT isdst=0 gmtoff=0 The version of the time zone data installed on my system (GNU/Linux Debian unstable) may not match the version of the files I'm looking at (2003a) but I didn't think that the LMT name was something terribly recent. If look directly at the binary data for this zone on my system, I see that it does indeed contain the string "LMT". Any idea where this is getting munged? I'm trying to generate tests for my code based on the output of zdump, but I'm getting weird failures because of this problem. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/

2 2

RE: Strange output from zdump for 2038
by Olson, Arthur David (NIH/NCI) July 21, 2003

July 21, 2003

The zdump manual page notes the output to be expected when using the -v option: -v For each zonename on the command line, print the time at the lowest possible time value, the time one day after the lowest possible time value, the times both one second before and exactly at each detected time discontinuity, the time at one day less than the highest possible time value, and the time at the highest possible time value, Each line ends with isdst=1 if the given time is Daylight Saving Time or isdst=0 otherwise. So the two 1901 lines and the two 2038 lines are to be expected. --ado -----Original Message----- From: Dave Rolsky [mailto:autarch@urth.org] Sent: Saturday, July 19, 2003 4:34 PM To: tz(a)lecserver.nci.nih.gov Subject: Re: Strange output from zdump for 2038 On Sat, 19 Jul 2003, Dave Rolsky wrote: > autarch@houseabsolute:~/DateTime/modules/DateTime-TimeZone$ zdump -v Asia/Aqtau | grep 2038 > > Asia/Aqtau Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 07:14:07 2038 AQTT isdst=0 gmtoff=14400 > Asia/Aqtau Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 07:14:07 2038 AQTT isdst=0 gmtoff=14400 > > Surely that's not right ;) I'd suggest that it's better to simply not > output anything rather than output bad data. Obviously this is related to > the 32-bit-ness of time_t, and is probably really a zic problem. The same problem occurs at the other end of integer: Africa/Abidjan Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 20:29:44 1901 GMT isdst=0 gmtoff=-968 Africa/Abidjan Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 20:29:44 1901 GMT isdst=0 gmtoff=-968 -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/

3 2

RE: Strange output from zdump for 2038
by Olson, Arthur David (NIH/NCI) July 21, 2003

July 21, 2003

> The point is, however, that the gmtoff values are rubbish, the result of > using signed 32-bit values to model mathematical integers. The gmtoff values being output do seem to be the difference (in seconds) between UTC and local time. (It's true that the appearance of "GMT" is bogus but, as noted earlier, that seems to be a GNU challenge rather than a timeezone-package-as distributed problem.) --ado -----Original Message----- From: John Cowan [mailto:cowan@mercury.ccil.org] Sent: Monday, July 21, 2003 9:01 AM To: Olson, Arthur David (NIH/NCI) Cc: tz(a)lecserver.nci.nih.gov Subject: Re: Strange output from zdump for 2038 Olson, Arthur David (NIH/NCI) scripsit: > So the two 1901 lines and the two 2038 lines are to be expected. The point is, however, that the gmtoff values are rubbish, the result of using signed 32-bit values to model mathematical integers. > > Asia/Aqtau Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 07:14:07 2038 AQTT > isdst=0 gmtoff=14400 > > Asia/Aqtau Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 07:14:07 2038 AQTT > isdst=0 gmtoff=14400 > Africa/Abidjan Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 20:29:44 1901 GMT > isdst=0 gmtoff=-968 > Africa/Abidjan Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 20:29:44 1901 GMT > isdst=0 gmtoff=-968 -- My confusion is rapidly waxing John Cowan For XML Schema's too taxing: jcowan(a)reutershealth.com I'd use DTDs http://www.reutershealth.com If they had local trees -- http://www.ccil.org/~cowan I think I best switch to RELAX NG.

1 0

Re: FW: The zrd zone file reader
by Robert Elz July 21, 2003

July 21, 2003

When one sees code like ... long test = 0x01020304; if ((char *)&test == "\0x01\0x02\0x03\0x04") return s; it is a fair indication that the rest of it isn't going to be worth bothering about ... kre

1 0

Strange output from zdump for 2038
by Dave Rolsky July 19, 2003

July 19, 2003

autarch@houseabsolute:~/DateTime/modules/DateTime-TimeZone$ zdump -v Asia/Aqtau | grep 2038 Asia/Aqtau Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 07:14:07 2038 AQTT isdst=0 gmtoff=14400 Asia/Aqtau Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 07:14:07 2038 AQTT isdst=0 gmtoff=14400 Surely that's not right ;) I'd suggest that it's better to simply not output anything rather than output bad data. Obviously this is related to the 32-bit-ness of time_t, and is probably really a zic problem. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/

1 1

The zrd zone file reader
by John Cowan July 18, 2003

July 18, 2003

I am submitting the following short program for possible inclusion in the next release of tzcode. Zrd (zone reader) is a program that dumps the contents of a binary zoneinfo file. It does not depend on the existing library in any way (except that it calls gmtime, but any gmtime will do), and provides a direct view into the contents of zoneinfo files. I have dedicated the program to the public domain. ===== cut here ==== /* zrd - a routine to dump the contents of a binary timezone file * Define ZONEINFO to be the directory where the timezone files are, * typically "/usr/share/zoneinfo/". * This program requires only stdio and "gmtime". * Public domain source by John Cowan <cowan(a)ccil.org> */ # define ZONEINFO "/usr/share/zoneinfo/" # include <stdio.h> # include <time.h> /* A handy routine that converts from network order * (big-endian) 32-bit values to local order. * It tests what local order is, and is not the most * efficient conceivable routine, but works OK * for this application. */ long my_ntohl(long s) { long r; char *ps; char *pr; long test = 0x01020304; if ((char *)&test == "\0x01\0x02\0x03\0x04") return s; ps = (char *) &s; pr = (char *) &r; pr[0] = ps[3]; pr[1] = ps[2]; pr[2] = ps[1]; pr[3] = ps[0]; return r; } /* The header of a timezone file. * It is followed by: * tzh_timecnt 32-bit values representing time transitions; * tzh_timecnt 1-byte indexes into the time type table; * the time type table, containing tzh_typecnt "struct ttinfo" elements; * the leap-second table, containing tzh_leapcnt "struct ttleap" elements; * tzh.isstdcnt 1-byte flags indicating if transitions are * based on local standard time or local current ("wall") time * tz.isgmtcnt 1-byte flags indicating if transitions are * based on UTC or local time */ struct tzhead { char tzh_magic[4]; /* magic number */ char tzh_reserved[16]; /* reserved for future use */ long tzh_ttisgmtcnt; /* coded number of trans. time flags */ long tzh_ttisstdcnt; /* coded number of trans. time flags */ long tzh_leapcnt; /* coded number of leap seconds */ long tzh_timecnt; /* coded number of transition times */ long tzh_typecnt; /* coded number of local time types */ long tzh_charcnt; /* coded number of abbr. chars */ }; /* A time type object */ struct ttinfo { long tt_gmtoff; /* offset of this time type from UTC */ char tt_isdst; /* whether this is a DST time type */ char tt_abbrind; /* index into the timezone name abbreviations */ }; /* A leap second object */ struct ttleap { long tt_time; /* The leap second */ long tt_seconds; /* New value of TAI - UTC - 10 */ }; char tzfilename[1024]; /* Filename of the timezone file */ FILE *tz; /* File stream for reading the file */ struct tzhead t; /* The file's header */ char tzdata[4096]; /* The rest of the file */ long tzsize; /* Size of tzdata in use */ /* Pointers to different parts of tzdata */ long *timep; char *timetypep; char *xtypep; struct ttinfo *typep; char *charp; struct ttleap *leapp; char *stdp; char *gmtp; main(argc, argv) int argc; char *argv[]; { int i; long gmtoff; int gmtsign; long clock; struct tm *d; char magic[5]; /* Validate command line and load header */ if (argc != 2) { fprintf(stderr, "usage: %s continent/location\n", argv[0]); exit(1); } strcpy(tzfilename, ZONEINFO); strcat(tzfilename, argv[1]); tz = fopen(tzfilename, "rb"); if (!tz) { fprintf(stderr, "%s: %s unknown\n", argv[0], argv[1]); exit(1); } fread(&t, sizeof(t), 1, tz); /* Localize values in the header */ strncpy(magic, t.tzh_magic, 4); magic[4] = 0; t.tzh_ttisgmtcnt = my_ntohl(t.tzh_ttisgmtcnt); t.tzh_ttisstdcnt = my_ntohl(t.tzh_ttisstdcnt); t.tzh_leapcnt = my_ntohl(t.tzh_leapcnt); t.tzh_typecnt = my_ntohl(t.tzh_typecnt); t.tzh_timecnt = my_ntohl(t.tzh_timecnt); t.tzh_charcnt = my_ntohl(t.tzh_charcnt); /* Read the rest of the file */ tzsize = fread(&tzdata, 1, sizeof(tzdata), tz); fclose(tz); /* Set up pointers to various sections */ timep = (long *)tzdata; timetypep = (char *)(timep + t.tzh_timecnt); xtypep = timetypep + t.tzh_timecnt; charp = xtypep + 6 * t.tzh_typecnt; /* alignment problem */ leapp = (struct ttleap *)(charp + t.tzh_charcnt); stdp = (char *)(leapp + t.tzh_leapcnt); gmtp = stdp + t.tzh_ttisstdcnt; /* Check for invalid file size */ if (tzdata + tzsize != gmtp + t.tzh_ttisgmtcnt) fprintf(stderr, "Warning: file is %ld bytes, expected %ld\n", tzsize + sizeof(t), (gmtp + t.tzh_ttisgmtcnt) - tzdata); /* Print magic number */ if (magic[0]) printf("TZ magic number is \"%s\" (normally \"TZif\")\n", magic); /* Print transition time table */ printf("%ld transition times:\n", t.tzh_timecnt); for (i = 0; i < t.tzh_timecnt; i++) { clock = my_ntohl(timep[i]); /* printf("\tat %ld use type %d\n", clock, timetypep[i]); */ d = gmtime(&clock); printf("\tat %4.4d-%2.2d-%2.2d %2.2d:%2.2d:%2.2d UTC (%ld) use type %d\n", d->tm_year + 1900, d->tm_mon+1, d->tm_mday, d->tm_hour, d->tm_min, d->tm_sec, clock, timetypep[i]); } /* Print time types table */ printf("%ld local time types:\n", t.tzh_typecnt); for (i = 0; i < t.tzh_typecnt; i++) { typep = (struct ttinfo *)(xtypep + i * 6); gmtoff = my_ntohl(typep->tt_gmtoff); if (gmtoff < 0) { gmtsign = -1; gmtoff = -gmtoff; } else if (gmtoff > 0) gmtsign = 1; else gmtsign = 0; printf("\ttype %d offset %2.2ld:%2.2ld:%2.2ld %s name (%d) %s", i, gmtsign*(gmtoff/3600), (gmtoff%3600)/60, gmtoff%60, typep->tt_isdst ? "isdst " : "notdst", typep->tt_abbrind, charp + typep->tt_abbrind); if (i < t.tzh_ttisstdcnt) printf(" %s", stdp[i] ? "std" : "wall"); if (i < t.tzh_ttisgmtcnt) printf(" %s", gmtp[i] ? "gmt" : "local"); printf("\n"); } /* Print time zone abbreviations */ printf("%ld bytes of abbreviations: [", t.tzh_charcnt); for (i = 0; i < t.tzh_charcnt; i++) if (charp[i]) putchar(charp[i]); else if (i != t.tzh_charcnt - 1) putchar('|'); printf("]\n"); /* Print leap second table */ printf("%ld leap second entries:\n", t.tzh_leapcnt); for (i = 0; i < t.tzh_leapcnt; i++) { clock = my_ntohl(leapp[i].tt_time); d = gmtime(&clock); printf("\tat %4.4d-%2.2d-%2.2d %2.2d:%2.2d:%2.2d UTC (%ld), TAI - UTC = %ld seconds\n", d->tm_year + 1900, d->tm_mon+1, d->tm_mday, d->tm_hour, d->tm_min, d->tm_sec, clock, my_ntohl(leapp[i].tt_seconds) + 10); } /* Print counts of gmt/local and std/wall flags (contents * have already been printed) */ printf("%ld std/wall flags\n", t.tzh_ttisstdcnt); printf("%ld gmt/local flags\n", t.tzh_ttisgmtcnt); exit(0); } ===== cut here ===== -- He made the Legislature meet at one-horse John Cowan tank-towns out in the alfalfa belt, so that jcowan(a)reutershealth.com hardly nobody could get there and most of http://www.reutershealth.com the leaders would stay home and let him go http://www.ccil.org/~cowan to work and do things as he pleased. --Mencken, _Declaration of Independence_

1 0

My confusion with Asia/Aqtau
by Dave Rolsky July 18, 2003

July 18, 2003

I'm trying to implement a parse/code generator based on the Olson DB _text_ files (not binary). I think I've got it mostly working, but there's some strange edge cases. One of them involves Asia/Aqtau, and I'm trying to figure out if I'm _really_ understanding what the file indicates. The observances for this zone include the following: 5:00 RussiaAsia AQT%sT 1995 Sep lastSun # Aqtau Time 4:00 RussiaAsia AQT%sT The RussiaAsia rules include the following rules which apply to those observances: Rule RussiaAsia 1993 max - Mar lastSun 2:00s 1:00 S Rule RussiaAsia 1993 1995 - Sep lastSun 2:00s 0 - Rule RussiaAsia 1996 max - Oct lastSun 2:00s 0 - By my reading, this indicates the following transitions: * On Sep 24, 1995 at 00:00:00 _local_ time, the offset from UTC changes from 05:00 to 04:00. However, the DST rule is still in effect, so the total offset goes from 06:00 to 05:00. * On Sep 24, 1995 at 01:00:00 local time (2:00s == 1:00 wall when DST is in effect), the rule changes so that DST is no longer in effect, and the cumulative offset goes from 05:00 to 04:00. Is this _really_ correct? It seems awfully strange to have an observance change so close to a DST change. And if cases like these are possible, it's really going to complicate my code. But if it is correct, I do want to get it right in my code. OTOH, if it's wrong, and such things don't happen, I'd be just as happy to leave me code as is ;) -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/

1 0