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