proposed tz patches for Indiana, New Brunswick, Gaza, etc.
Arthur David Olson
olsona at lecserver.nci.nih.gov
Sun Jan 22 23:28:16 UTC 2006
> I vaguely recall that it's because zic recognizes this situation
> specially, and refuses to create the two hour-apart transitions that
> the rules would require if applied strictly. Instead, it merges the
> transitions in the common-sense way.
A hunt in the archives shows that Paul's vague recollection is correct.
Historically there have been places that went through the same transition
that's about to happen in Knox; these places have done it without
changing their wall clocks. Zic is set up to recognize the situation and
"do the right thing;" given DOT's docket, the right way may not be DOT's way.
For those on deadlines: to get DOT-mandated behavior,
one ugly possibility is to lie by a second:
instead of having a Zone such as...
Zone America/Indiana/Knox -5:46:30 - LMT 1883 Nov 18 12:13:30
...
-5:00 - EST 2006 Apr 2 2
-6:00 US C%sT
...you'd have a zone such as...
Zone America/Indiana/Knox -5:46:30 - LMT 1883 Nov 18 12:13:30
...
-5:00 - EST 2006 Apr 2 1:59:59
-6:00 US C%sT
Matters at hand are to reconsider zic's change-collapsing behavior,
document the change-collapsing behavior if it's kept,
and--if DOT-mandated behavior is desired--figure out the best way to
get that behavior out of the change-collapsing zics already out in the field.
Below find excerpts from three relevant messages from 1996.
--ado
===============================================================================
> From eggert at twinsun.com Wed May 1 18:40:19 1996
> Return-Path: <eggert at twinsun.com>
> Received: from alcor.twinsun.com by elsie.nci.nih.gov (4.1/SMI-4.1)
> id AA26147; Wed, 1 May 96 18:40:19 EDT
> Received: from der.twinsun.com (der.twinsun.com [192.54.239.42]) by alcor.twinsun.com (8.6.12/8.6.5) with ESMTP id PAA02100 for <tz at elsie.nci.nih.gov>; Wed, 1 May 1996 15:35:54 -0700
> Received: from bird.twinsun.com by der.twinsun.com (SMI-8.6/SMI-SVR4)
> id PAA17702; Wed, 1 May 1996 15:40:05 -0700
> Received: by bird.twinsun.com (SMI-8.6/SMI-SVR4)
> id PAA11877; Wed, 1 May 1996 15:40:04 -0700
> Date: Wed, 1 May 1996 15:40:04 -0700
> Message-Id: <199605012240.PAA11877 at bird.twinsun.com>
> From: Paul Eggert <eggert at twinsun.com>
> To: tz at elsie.nci.nih.gov
> Subject: bug in zic for Rule and Zone changing simultaneously?
> Status: RO
>
> I found 23 bugs in the latest tz database. I enclose two detailed
> examples below, and a brief summary of all the bugs. It appears that
> zic has problems when applying Zone and Rule changes simultaneously.
>
>
> Example 1. The edited input is:
>
> # Rule NAME FROM TO TYPE IN ON AT SAVE LET
> Rule Falk 1985 max - Sep Sun>=9 0:00 1:00 D
> # Zone NAME GMTOFF RULES FORMAT [UNTIL]
> Zone Atlantic/Stanley -3:00 Falk E%sT 1985 Sep 15
> -4:00 Falk A%sT
>
> The zdump -v output is:
>
> Atlantic/Stanley Sun Sep 15 02:59:59 1985 GMT = Sat Sep 14 23:59:59 1985 EST isdst=0
> Atlantic/Stanley Sun Sep 15 03:00:00 1985 GMT = Sat Sep 14 23:00:00 1985 AST isdst=0
> Atlantic/Stanley Sun Sep 15 03:59:59 1985 GMT = Sat Sep 14 23:59:59 1985 AST isdst=0
> Atlantic/Stanley Sun Sep 15 04:00:00 1985 GMT = Sun Sep 15 01:00:00 1985 ADT isdst=1
>
> zdump claims that inhabitants of Stanley changed their clocks twice
> that night, when they changed them only once. The transition should
> have been from
> 1985-09-14 23:59:59 -0300 (EST) to
> 1985-09-15 00:00:00 -0400 (ADT), but zic applied `Zone' first, yielding
> 1985-09-14 23:00:00 -0200 (EDT), and then one hour later applied `Rule',
> yielding the proper time afterwards; but there's a one-hour period of
> incorrect times.
>
>
> Example 2. The input is:
>
> # Rule NAME FROM TO TYPE IN ON AT SAVE LET
> Rule Regina 1905 only - Sep 1 0:00 0 S
> # Zone NAME GMTOFF RULES FORMAT [UNTIL]
> Zone America/Regina -6:58:36 - LMT 1905 Sep
> -7:00 Regina M%sT 1966 Apr 15
>
> The zdump output is:
>
> America/Regina Fri Sep 1 06:58:35 1905 GMT = Thu Aug 31 23:59:59 1905 LMT isdst=0
> America/Regina Fri Sep 1 06:58:36 1905 GMT = Thu Aug 31 23:58:36 1905 LMT isdst=0
> America/Regina Fri Sep 1 06:59:59 1905 GMT = Thu Aug 31 23:59:59 1905 LMT isdst=0
> America/Regina Fri Sep 1 07:00:00 1905 GMT = Fri Sep 1 00:00:00 1905 MST isdst=0
>
> Again, there are two transitions where there should be one, and it's
> because the Zone was applied before the Rule, when they were meant to
> be applied simultaneously. In this case, the erroneous period is only
> 84 seconds long.
>
>
> Here is a list of the 23 bugs I found. Each line has the following
> columns:
>
> timezone name
> first time_t value in the erroneous period (1)
> first time_t value after the erroneous period is over (2)
> ctime applied to (1)
> ctime applied to (2)
>
> America/Asuncion 134017200 134020800 Sun Mar 31 23:00:00 1974 Mon Apr 1 00:00:00 1974
> America/Barbados -1199217720 -1199217600 Thu Dec 31 23:58:00 1931 Fri Jan 1 00:00:00 1932
> America/Belize -1822500432 -1822500000 Sun Mar 31 23:52:48 1912 Mon Apr 1 00:00:00 1912
> America/Costa_Rica -1545071040 -1545069600 Fri Jan 14 23:36:00 1921 Sat Jan 15 00:00:00 1921
> America/El_Salvador -1546279392 -1546279200 Fri Dec 31 23:56:48 1920 Sat Jan 1 00:00:00 1921
> America/Juneau 436352400 436356000 Sun Oct 30 01:00:00 1983 Sun Oct 30 01:00:00 1983
> ...
===============================================================================
> From ado Tue May 14 14:31:50 1996
> Return-Path: <ado>
> Received: by elsie.nci.nih.gov (4.1/SMI-4.1)
> id AA07673; Tue, 14 May 96 14:31:50 EDT
> Date: Tue, 14 May 96 14:31:50 EDT
> From: ado (Arthur David Olson)
> Message-Id: <9605141831.AA07673 at elsie.nci.nih.gov>
> To: tz
> Subject: Simultaneous zone and DST changes
> Status: RO
>
> The basic challenge with places such as Stanley (where a time-zone shift and
> a DST change were done at the same instant in 1985, resulting in no change of
> wall clock time) is that there's an hour when such a place is neither fish nor
> fowl. Here's a table summarizing what's happening on September 14/15 1995
> in five different circumstances; each row of the table gives data for a
> particular instant in time. The circumstances:
> 1. What's happening in places that run on GMT
> 2. What's happening in (hypothetical) places that always run on EST/EDT
> using Falkland rules
> 3. What's happening in (hypothetical) places that always run on AST/ADT
> using Falkland rules
> 4. What zdump tells us is currently produced by zic for Stanley
> 5. And what we (presumably) really want for Stanley.
> ===============================================================================
> GMT-------|Always-ExT-----|Always-AxT-----|Stanley (now)--|Stanley (wanted)
> 15 2:59:59|14 23:59:59 EST|14 22:59:59 AST|14 23:59:59 EST|14 23:59:59 EST
> 15 3:00:00|15 01:00:00 EDT|14 23:00:00 AST|14 23:00:00 AST|15 00:00:00 ADT/EST
> 15 3:59:59|15 01:59:59 EDT|14 23:59:59 AST|14 23:59:59 AST|15 00:59:59 ADT/EST
> 15 4:00:00|15 02:00:00 EDT|15 01:00:00 ADT|15 01:00:00 ADT|15 01:00:00 ADT
> ===============================================================================
> The "Stanley (wanted)" stuff matches neither the "Always ExT" stuff nor the
> "Always AxT" stuff (regardless of whether you pick ADT or EST for Stanley to
> use as a time zone abbreviation during the strange hour).
>
> Among the ways to get from "Stanley (now)" to "Stanley (wanted)":
>
> 1. Hard code the transition hour--that is, where there are now lines that read...
>
> Zone Atlantic/Stanley -3:51:24 - LMT 1890
> -3:51 - SMT 1912 Mar 12
> -4:00 Falk A%sT 1983 May
> -3:00 Falk E%sT 1985 Sep 15
> -4:00 Falk A%sT
>
> ...add a line to cover the hour in 1985...
>
> Zone Atlantic/Stanley -3:51:24 - LMT 1890
> -3:51 - SMT 1912 Mar 12
> -4:00 Falk A%sT 1983 May
> -3:00 Falk E%sT 1985 Sep 15
> -3:00 - EST 1985 Sep 15 1:00 # <<<<
> -4:00 Falk A%sT
>
> 2. Set up zic to notice situations such as the above and "do the right thing."
> This would involve a code change something like this (with the "horrid
> special case" check perhaps made more strict):
> ===============================================================================
> ...
> ===============================================================================
> I lean toward the second approach; are there any better ideas out there?
>
> --ado
===============================================================================
> From eggert at twinsun.com Wed May 15 03:55:30 1996
> Return-Path: <eggert at twinsun.com>
> Received: from alcor.twinsun.com by elsie.nci.nih.gov (4.1/SMI-4.1)
> id AA10516; Wed, 15 May 96 03:55:30 EDT
> Received: from der.twinsun.com (der.twinsun.com [192.54.239.42]) by alcor.twinsun.com (8.6.12/8.6.5) with ESMTP id AAA03404; Wed, 15 May 1996 00:49:16 -0700
> Received: from bird.twinsun.com by der.twinsun.com (SMI-8.6/SMI-SVR4)
> id AAA19194; Wed, 15 May 1996 00:55:12 -0700
> Received: by bird.twinsun.com (SMI-8.6/SMI-SVR4)
> id AAA01768; Wed, 15 May 1996 00:55:11 -0700
> Date: Wed, 15 May 1996 00:55:11 -0700
> Message-Id: <199605150755.AAA01768 at bird.twinsun.com>
> From: Paul Eggert <eggert at twinsun.com>
> To: ado at elsie.nci.nih.gov
> Cc: tz at elsie.nci.nih.gov
> In-Reply-To: <9605141831.AA07673 at elsie.nci.nih.gov> (ado at elsie.nci.nih.gov)
> Subject: Re: Simultaneous zone and DST changes
> Status: RO
>
> Date: Tue, 14 May 96 14:31:50 EDT
> From: ado at elsie.nci.nih.gov (Arthur David Olson)
>
> I lean toward the second approach; are there any better ideas out there?
>
> How about the following implementation of the 2nd approach instead?
> It's the same basic idea, except that the two transitions are merged
> if their before-transition localtimes are the same (or if the latter
> precedes the former!). This should avoid the horridness of the 1-hour
> special case.
>
> This patch fixes bugs in the following transitions:
>
> 1919-03-01 Europe/Brussels
> 1973-04-29 America/Menominee
> 1983-10-30 America/Juneau
> 1985-04-19 Asia/Istanbul
> 1985-09-15 Atlantic/Stanley
>
> ===================================================================
> RCS file: RCS/zic.c,v
> retrieving revision 1996.6
> retrieving revision 1996.6.1.2
> diff -c -r1996.6 -r1996.6.1.2
> *** zic.c 1996/05/03 02:49:23 1996.6
> --- zic.c 1996/05/15 07:51:50 1996.6.1.2
> ***************
> *** 1397,1406 ****
> if (isdsts[0] == 0)
> while (attypes[fromi].type == 0)
> ++fromi; /* handled by default rule */
> ! for ( ; fromi < timecnt; ++fromi)
> if (toi == 0 ||
> attypes[toi - 1].type != attypes[fromi].type)
> attypes[toi++] = attypes[fromi];
> timecnt = toi;
> }
> /*
> --- 1397,1416 ----
> if (isdsts[0] == 0)
> while (attypes[fromi].type == 0)
> ++fromi; /* handled by default rule */
> ! for ( ; fromi < timecnt; ++fromi) {
> ! if (toi != 0
> ! && ((attypes[fromi].at
> ! + gmtoffs[attypes[toi - 1].type])
> ! <= (attypes[toi - 1].at
> ! + gmtoffs[toi == 1 ? 0
> ! : attypes[toi - 2].type]))) {
> ! attypes[toi - 1].type = attypes[fromi].type;
> ! continue;
> ! }
> if (toi == 0 ||
> attypes[toi - 1].type != attypes[fromi].type)
> attypes[toi++] = attypes[fromi];
> + }
> timecnt = toi;
> }
> /*
More information about the tz
mailing list