- tz - lists.iana.org

zic leapseconds bug
by David Robinson June 13, 2006

June 13, 2006

There appears to be a bug in zic when leapseconds are provided, for any time zone transition near a leapsecond. The bug is that after reading in the Leaps as Posix seconds in the trans[] array, adjleap() is called. This converts these to genuine UTC seconds. However, this array is then used to fixup transition times which are in posix seconds, by for (i = 0; i < timecnt; ++i) { j = leapcnt; while (--j >= 0) if (ats[i] >= trans[j]) { ats[i] = tadd(ats[i], corr[j]); break; } } ats[] is stored in posix seconds, but trans[] is in leap seconds. The effect is that for Europe/London, the transition on 1996-01-01 00:00:00 is actually set to be at 1995-12-31 23:59:60, i.e. on the leap second (820454419). Any transition in the range 1996-01-01 00:00:00 to 00:00:18 is similarly off by one second. The fix is obvious in principle (have a copy of trans[] that isn't leap-second adjusted, and use that in the code above), but not all the uses of trans[] in the code are obvious to me (what are Rolling leapsecs?). I'd also suggest that zic reject any transition in its input with a second=60. It's usually run without a leap file so there's no point in implementing the correct behaviour for that case. Many thanks, David Robinson

2 1

FW: zic leapseconds bug
by Olson, Arthur David (NIH/NCI) [E] June 13, 2006

June 13, 2006

David Robinson is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: David Robinson [mailto:drtr@apache.org] Sent: Tuesday, June 13, 2006 11:07 AM To: tz(a)lecserver.nci.nih.gov Subject: zic leapseconds bug There appears to be a bug in zic when leapseconds are provided, for any time zone transition near a leapsecond. The bug is that after reading in the Leaps as Posix seconds in the trans[] array, adjleap() is called. This converts these to genuine UTC seconds. However, this array is then used to fixup transition times which are in posix seconds, by for (i = 0; i < timecnt; ++i) { j = leapcnt; while (--j >= 0) if (ats[i] >= trans[j]) { ats[i] = tadd(ats[i], corr[j]); break; } } ats[] is stored in posix seconds, but trans[] is in leap seconds. The effect is that for Europe/London, the transition on 1996-01-01 00:00:00 is actually set to be at 1995-12-31 23:59:60, i.e. on the leap second (820454419). Any transition in the range 1996-01-01 00:00:00 to 00:00:18 is similarly off by one second. The fix is obvious in principle (have a copy of trans[] that isn't leap-second adjusted, and use that in the code above), but not all the uses of trans[] in the code are obvious to me (what are Rolling leapsecs?). I'd also suggest that zic reject any transition in its input with a second=60. It's usually run without a leap file so there's no point in implementing the correct behaviour for that case. Many thanks, David Robinson

1 0

tzdata Copyright
by Wolber, Richard C June 7, 2006

June 7, 2006

Greetings, Who is considered the "copyright holder" of the tzdata package? ..Chuck.. -- Chuck Wolber (Meriadoc Sandybanks) Electronic Flight Bag Crew Information Systems/ Linux Wonk 253.576.1154 "At the back of the Daylight Saving scheme I detect the bony, blue-fingered hand of Puritanism, eager to push people into bed earlier, and get them up earlier, to make them healthy, wealthy and wise in spite of themselves." - Robertson Davies, The diary of Samuel Marchbanks Clarke, Irwin (1947), XIX, Sunday

1 0

Australian time zone abbreviations
by Chuck Soper June 2, 2006

June 2, 2006

I recently found this Australian government web page on time zones: <http://www.australia.gov.au/about-australia-13time> And this government web page lists time zone names and abbreviations: <http://www.bom.gov.au/climate/averages/tables/daysavtm.shtml> I have read the notes in the australasia tzdata file. Should the current official time zone abbreviations be used rather than the popular ones? This would be my preference. Perhaps, the older tz abbreviations without the "A" for Australia could be maintained for dates in the past similar to using PWT (Pacific Wartime) for Pacific Time? Thanks, Chuck

5 4

Bern is the Capital of Switzerland
by Didier CLERC June 1, 2006

June 1, 2006

Hello, Why is the timezone for Switzerland Europe/Zurich and not Europe/Bern ? Bern is the Capitale of Switzerland. Considering Zurich to be the capitale of Switzerland is an offense to most of the Swiss. Thank you for your answer, Didier CLERC

1 0

RE: Possible TZ Data Errors with every 1st / 2nd / 3rd Xday of the month
by Andy Lipscomb June 1, 2006

June 1, 2006

No, in that case at least, the data is correct. The second Saturday of a month can be between the 8th and the 14th, inclusive; this year, the second Saturday of October is the 14th. Since the changeover occurs at 24:00 on that Saturday and Unix doesn't like 24:00, it is coded as 0:00 the following day, which is the 15th this year, and in general can run from the 9th to the 15th. Thus, Sun>=9 is correct. (This is not the "second Sunday," but the "Sunday after the second Saturday." USA readers will see the resemblance to Election Day.) ________________________________ From: Dr Hingston [mailto:dr.hingston@paradise.net.nz] Sent: Wed 31 May 2006 04:31 To: tz(a)lecserver.nci.nih.gov Subject: Possible TZ Data Errors with every 1st / 2nd / 3rd Xday of the month Dear List Members Woops, seems I got the address wrong, my apologies! I hope this is better! Regarding: Rule Chile 1999 max - Oct Sun>=9 4:00u 1:00 S Rule Chile 2000 max - Mar Sun>=9 3:00u 0 - The expression Sun>=9 from the above rules would appear to me to be incorrect, as it suggests the third Sunday in some years. e.g. October this year. Summary: Supreme Decree Number 1,489 (6 October 1970) - This law, enacted during the presidency of Eduardo Frei Montalva, declared that Daylight Saving Time will advance clocks by one hour, beginning the second Saturday of October, and ending the second Saturday of March. Chilean time is administered by the Chilean Navy's Hydrographic and Oceanographic Service (SHOA). On discussion with the Chilean Consulate the above is confirmed, and time for changeover is midnight Saturday (I take to mean 00:00 Sunday)

2 1

Possible TZ Data Errors with every 1st / 2nd / 3rd Xday of the month
by Dr Hingston May 31, 2006

May 31, 2006

Dear List Members Woops, seems I got the address wrong, my apologies! I hope this is better! Regarding: Rule Chile 1999 max - Oct Sun>=9 4:00u 1:00 S Rule Chile 2000 max - Mar Sun>=9 3:00u 0 - The expression Sun>=9 from the above rules would appear to me to be incorrect, as it suggests the third Sunday in some years. e.g. October this year. References: http://www.twinsun.com/tz/tz-link.ht (!) which lists: http://webexhibits.org/daylightsaving/chile.html Summary: Supreme Decree Number 1,489 (6 October 1970) - This law, enacted during the presidency of Eduardo Frei Montalva, declared that Daylight Saving Time will advance clocks by one hour, beginning the second Saturday of October, and ending the second Saturday of March. Chilean time is administered by the Chilean Navy's Hydrographic and Oceanographic Service (SHOA). On discussion with the Chilean Consulate the above is confirmed, and time for changeover is midnight Saturday (I take to mean 00:00 Sunday) It would seem to be correct, to me, if it were stated as Sun>=8. Similarly, if I am correct, then there are quite a number of other instances in the database where the expression Sun>=9 perhaps might be more correctly stated as Sun>=8? Extrapolating further, if I may, some of the other instances may also be incorrect, e.g. Sun>=16 etc. Some examples: Rule ChileAQ 1966 1997 - Oct Sun>=9 0:00 1:00 S Rule Belize 1919 1943 - Feb Sun>=9 0:00 0 S Rule Falk 1985 2000 - Sep Sun>=9 0:00 1:00 S Rule Falk 1986 2000 - Apr Sun>=16 0:00 0 - Rule GB-Eire 1945 1946 - Oct Sun>=2 2:00s 0 GMT Rule GB-Eire 1946 only - Apr Sun>=9 2:00s 1:00 BST Where a week day is stipulated as the Xth day of the month then I believe the correct references should be >=1, >=8, >= 15, >= 22 etc. Therefore I question other numbers, of course they may be correct, however this does seem to suggest careful scrutiny of those numbers is indicated. I'd be grateful for list consideration and comment please. Kind regards David Hingston

1 0

Tzcode2006g.tar.gz and tzdata2006g.tar.gz
by Olson, Arthur David (NIH/NCI) [E] May 31, 2006

May 31, 2006

The files... ftp://elsie.nci.nih.gov/pub/tzcode2006g.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2006g.tar.gz ...are now available; these reflect the northamerica changes circulated last week on the time zone mailing list by Paul Eggert. --ado

2 1

FW: Corrections to latitudes/longitudes in zone.tab
by Olson, Arthur David (NIH/NCI) [E] May 31, 2006

May 31, 2006

Andy McDonald is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Andy McDonald [mailto:andy@stemhaus.com] Sent: Tuesday, May 23, 2006 12:28 AM To: tz(a)lecserver.nci.nih.gov Subject: Corrections to latitudes/longitudes in zone.tab Hi, A very very minor point, but I've run across a few inaccurate latitudes/longitudes in tz's zone.tab (2006g and earlier): Corrected lat/long zone.tab lat/long America/Argentina/Tucuman: -0265000, -0651300 -0312400, -0641100 America/Inuvik: +0682200, -1334400 +0682500, -1133000 America/Rainy_River: +0484300, -0943400 +0484300, -0942900 America/Rankin_Inlet +0624800, -0920500 +0624500, -0921000 America/Scoresbysund: +0703000, -0215800 +0703000, -0221500 (Tucuman's latitude and longitude in zone.tab are those of America/Argentina/Cordoba.) The corrected values come from playing with my Firefox extension (http://www.stemhaus.com/firefox/foxclocks/) and Google Earth, and are of course entirely subjective. Regards, Andy McDonald

3 2

Manpage License question
by Martin Schulze May 30, 2006

May 30, 2006

Hi, the man-pages package for GNU/Linux has incorporated some of the tz manpages that are also distributed in tzcode$year.tar.gz, namely zic.8, zdump.8 and tzselect.8. They lack a copyright notice and a license statement. The tzcode2006g.tar.gz lacks this information as well. What license are these pages distributed under? I assume it's the BSD license, but I'd better ask. Please keep Michael Kerrisk copied who is the current man-pages maintainer, I'm just the Debian downstream. Thanks and kind regards, Joey -- Never trust an operating system you don't have source for!

1 0