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@twinsun.com Wed May 1 18:40:19 1996 Return-Path: <eggert@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@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@bird.twinsun.com> From: Paul Eggert <eggert@twinsun.com> To: tz@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@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@twinsun.com Wed May 15 03:55:30 1996 Return-Path: <eggert@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@bird.twinsun.com> From: Paul Eggert <eggert@twinsun.com> To: ado@elsie.nci.nih.gov Cc: tz@elsie.nci.nih.gov In-Reply-To: <9605141831.AA07673@elsie.nci.nih.gov> (ado@elsie.nci.nih.gov) Subject: Re: Simultaneous zone and DST changes Status: RO

Date: Tue, 14 May 96 14:31:50 EDT From: ado@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; } /*