January 2006 - tz - lists.iana.org

RE: Docket No. 2005-22114
by Olson, Arthur David (NIH/NCI) [E] Jan. 24, 2006

Jan. 24, 2006

> This cannot be exactly what was intended, because 2:00 a.m. EST corresponds to 1:00 a.m. CST, at which point clocks in the Central time zone will not > spring forward for another hour. Therefore, as written, the rule requires that a clock in the affected area must jump backwards from 02:00 EST to 01:00 > CST, and then an hour later jump ahead from 02:00 CST to 03:00 CDT. In other words, the currently-required clock transitions would look like this: > > 01:59:59 EST > ... and then, one second later,... > 01:00:00 CST > ... > ... > ... and then, one hour later,... > 01:59:59 CST > ... and then, one second later,... > 03:00:00 CDT > > We doubt whether you really intended that the citizens of Vincennes, Indiana should stay up in the middle of the night and change their clocks twice. The DOT-related problem is the over-zealous railroad engineer who parks his train for an hour when the clock falls back and then runs at high speed (increasing the chance of an accident) to make up time when the clock springs forward. I will not tempt fate by putting a smiley face here. In an unrelated matter, page 57 of the docket reads (in part) "We expect the economic impact of this proposed rule to be so minimal that a full Regulatory Evaluation...is unnecessary." Which raises the question: if changing clocks by an hour has such minimal economic impact, why are we playing the DST game in the first place? --ado

6 7

RE: Docket No. 2005-22114
by Olson, Arthur David (NIH/NCI) [E] Jan. 24, 2006

Jan. 24, 2006

Recall that a message sent to the time zone mailing list isn't automatically forwarded unless it's from someone on the list (this is an anti-spam measure). I typically run through the raw feed each Monday and forward any relevant stuff from non-list senders. Since Paul sent the message to Judith S. Kaleta I've been checking on a daily basis; there's been nothing sent to the list yet. If we could just get Jon Stewart to "cover" the "story"... --ado -----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Monday, January 23, 2006 7:00 PM To: tz(a)lecserver.nci.nih.gov Subject: Re: Docket No. 2005-22114 "Bill Bonnett" <news(a)abdicate.net> writes: > Has anyone bothered to contact DOT about this? Yes, I emailed Judith S. Kaleta, of the Office of the General Counsel of the DOT, and CC'ed to this list. No response yet.

1 0

FW: Re: Docket No. 2005-22114
by Arthur David Olson Jan. 24, 2006

Jan. 24, 2006

Rodrigo Severo is not on the time zone list at the address shown below; direct replies appropriately. --ado >From rsevero.lists(a)gmail.com Tue Jan 24 06:04:34 2006 ... From: Rodrigo Severo <rodrigo.lists(a)fabricadeideias.com> Sender: rsevero.lists(a)gmail.com ... On 1/23/06, Paul Eggert <eggert(a)cs.ucla.edu> wrote: > > "David Braverman" <david(a)inner-drive.com> writes: > > It is a bit ironic that the US is less efficient than Brazil in fixing > obviously-broken regulations like this. I'm sorry but I have to ask: where is the irony in this? I hope the answer isn't obvious to people from US and I'm not seeing it just because I'm brazilian ;) Rodrigo Severo

1 0

RE: off-by-one-hour error in OST Docket No. 2005-22114
by Paul Schauble Jan. 23, 2006

Jan. 23, 2006

Doesn't the first proposal have the problem that there is no 2:59:59 EST, the Eastern zone having changed to DST? ++PLS -----Original Message----- From: tz-request(a)elsie.nci.nih.gov [mailto:tz-request@elsie.nci.nih.gov] On Behalf Of Paul Eggert Sent: Friday, January 20, 2006 10:56 PM To: Judith S. Kaleta Cc: Time zone mailing list Subject: off-by-one-hour error in OST Docket No. 2005-22114 Judith S. Kaleta Office of the General Counsel US Dept. of Transportation Room 10428 400 Seventh St Washington, DC 20590 Dear Ms. Kaleta: I help maintain the public-domain tz database of time zone and daylight saving time transitions. This database contains code and data that represent the history of local time, and is used by many computers around the world. For details, please see <http://www.twinsun.com/tz/tz-link.htm>. Needless to say, we've been following the Indiana situation with interest. Deborah Goldsmith of Apple Computer, one of our correspondents, recently noted what appears to be a one-hour error in docket OST-2005-22114 <http://dmses.dot.gov/docimages/pdf95/382329_web.pdf>. Quoting from the first page of that document: DATES: The effective date of this rule is 2:00 a.m. EST Sunday, April 2, 2006, which is the changeover date from standard time to Daylight Saving Time. This cannot be exactly what was intended, because 2:00 a.m. EST corresponds to 1:00 a.m. CST, at which point clocks in the Central time zone will not spring forward for another hour. Therefore, as written, the rule requires that a clock in the affected area must jump backwards from 02:00 EST to 01:00 CST, and then an hour later jump ahead from 02:00 CST to 03:00 CDT. In other words, the currently-required clock transitions would look like this: 01:59:59 EST ... and then, one second later,... 01:00:00 CST ... ... ... and then, one hour later,... 01:59:59 CST ... and then, one second later,... 03:00:00 CDT We doubt whether you really intended that the citizens of Vincennes, Indiana should stay up in the middle of the night and change their clocks twice. Our correspondents have suggested two different ways out of this problem. First, and perhaps simplest, you could change the effective time of the rule from 2:00 a.m. EST to 3:00 a.m. EST. This will result in the following transition: 02:59:59 EST ... and then, one second later,... 03:00:00 CDT Second, if you prefer sticking to a 2:00 a.m. transition, you could append the following sentences: Counties that move from the Eastern to the Central Time Zone will switch directly from EST to CDT, so that their clocks need not change. From 2:00 a.m. CDT to 3:00 a.m. CDT these clocks will use CDT even though the rest of the Central Time Zone will still be using CST. This would result in the following transition: 01:59:59 EST ... and then, one second later,... 02:00:00 CDT Please let us know which solution (if any) you prefer, by writing to us in the time zone mailing list <tz(a)elsie.nci.nih.gov>. Thanks. Sincerely, Paul Eggert Computer Science Dept. 4532J Boelter Hall University of California Los Angeles, CA 90095-1596 +1 310 267 2254 (voice) eggert(a)ucla.edu (email)

2 1

RE: off-by-one-hour error in OST Docket No. 2005-22114
by Andy Lipscomb Jan. 23, 2006

Jan. 23, 2006

PLS> Doesn't the first proposal have the problem that there is no 2:59:59 EST, the Eastern zone having changed to DST? It really just requires the same caveat as the second one--that they will be on EST even with the rest of the Eastern zone having adopted EDT, for that one hour. [snipping down to the proposals...] Our correspondents have suggested two different ways out of this problem. First, and perhaps simplest, you could change the effective time of the rule from 2:00 a.m. EST to 3:00 a.m. EST. This will result in the following transition: 02:59:59 EST ... and then, one second later,... 03:00:00 CDT Second, if you prefer sticking to a 2:00 a.m. transition, you could append the following sentences: Counties that move from the Eastern to the Central Time Zone will switch directly from EST to CDT, so that their clocks need not change. From 2:00 a.m. CDT to 3:00 a.m. CDT these clocks will use CDT even though the rest of the Central Time Zone will still be using CST. This would result in the following transition: 01:59:59 EST ... and then, one second later,... 02:00:00 CDT

1 0

RE: FW: Indiana time zones
by Andy Lipscomb Jan. 23, 2006

Jan. 23, 2006

"First, Shanks says Vincennes and Indianapolis differed in many ways before 1964. For example, he says Vincennes observed DST in 1946 and from 1956 through 1963. I assume you merely copied Indianpolis's table to Vincennes for time stamps until now, which wouldn't be quite right." Correct. I bow to your superior research on that point. Second: "> In addition to the section above, the new zone will need to be added > to the zone.tab file. Vincennes' location is > +384042-0873058. My proposed patch had +384038-0873143 which is fairly close. (The LMT figures also diverged, presumably because of the coordinate difference.) My latitude and longitude are from Shanks." My figures come from the Census Bureau (with LMT computed from them, so that probably does explain the difference). "I'm not sure how Shanks (or anyone else) decides where Vincennes "is", given that one arc second of latitude is only 31 meters or so." The Census Bureau indicates that its figures are based on the approximate geographic center of the area, provided that point is actually in the area.

1 0

FW: Indiana time zones
by Olson, Arthur David (NIH/NCI) [E] Jan. 23, 2006

Jan. 23, 2006

Andy Lipscomb has been added to the time zone mailing list; this message predates the addition. --ado -----Original Message----- From: Andy Lipscomb [mailto:AndyLipscomb@decosimo.com] Sent: Friday, January 20, 2006 12:39 PM To: tz(a)lecserver.nci.nih.gov Cc: ewwa(a)chattanooga.net Subject: Indiana time zones Actually, there are seven other counties that are moving from Eastern to Central time. Since they, like Starke County, do so at the time change, they will simply skip the spring-forward--2:00 EST and 2:00 CDT are identical (both equal 21:00 UTC on the previous day). It appears to me that this requires creating a new zone for the other seven counties, which I show below. # From J. Andrew Lipscomb (2006-01-20): # Department of Transportation ruling http://www.dot.gov/affairs/dot0406.htm # adds eight new counties to the Central (America/Chicago) zone. Six are in # the Evansville area, two near Chicago. One of them (Starke) already has its # own entry; as for the other seven, the largest city in them (and an old # territorial capital) is Vincennes. I suggest that for the exemplar city of # the seven counties. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Indiana/Vincennes -5:50:04 - LMT 1883 Nov 18 12:09:56 -6:00 US C%sT 1920 -6:00 Indianapolis C%sT 1942 -6:00 US C%sT 1946 -6:00 Indianapolis C%sT 1955 Apr 24 2:00 -5:00 - EST 1957 Sep 29 2:00 -6:00 - CST 1958 Apr 27 2:00 -5:00 - EST 1969 -5:00 US E%sT 1971 -5:00 - EST 2006 Apr 2 2:00 -6:00 US C%sT In addition to the section above, the new zone will need to be added to the zone.tab file. Vincennes' location is +384042-0873058. And to cover Starke County: # From J. Andrew Lipscomb (2006-01-20): # The Department of Transportation placed Starke County back on Central time, # beginning at the 2006 DST start. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER Rule Starke 1947 1961 - Apr lastSun 2:00 1:00 D Rule Starke 1947 1954 - Sep lastSun 2:00 0 S Rule Starke 1955 1956 - Oct lastSun 2:00 0 S Rule Starke 1957 1958 - Sep lastSun 2:00 0 S Rule Starke 1959 1961 - Oct lastSun 2:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Indiana/Knox -5:46:30 - LMT 1883 Nov 18 12:13:30 -6:00 US C%sT 1947 -6:00 Starke C%sT 1962 Apr 29 2:00 -5:00 - EST 1963 Oct 27 2:00 -6:00 US C%sT 1991 Oct 27 2:00 -5:00 - EST 2006 Apr 2 2:00 -6:00 US C%sT

2 1

Re: proposed tz patches for Indiana, New Brunswick, Gaza, etc.
by Arthur David Olson Jan. 22, 2006

Jan. 22, 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(a)twinsun.com Wed May 1 18:40:19 1996 > Return-Path: <eggert(a)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(a)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(a)bird.twinsun.com> > From: Paul Eggert <eggert(a)twinsun.com> > To: tz(a)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(a)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(a)twinsun.com Wed May 15 03:55:30 1996 > Return-Path: <eggert(a)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(a)bird.twinsun.com> > From: Paul Eggert <eggert(a)twinsun.com> > To: ado(a)elsie.nci.nih.gov > Cc: tz(a)elsie.nci.nih.gov > In-Reply-To: <9605141831.AA07673(a)elsie.nci.nih.gov> (ado(a)elsie.nci.nih.gov) > Subject: Re: Simultaneous zone and DST changes > Status: RO > > Date: Tue, 14 May 96 14:31:50 EDT > From: ado(a)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; > } > /*

1 0

off-by-one-hour error in OST Docket No. 2005-22114
by Paul Eggert Jan. 21, 2006

Jan. 21, 2006

Judith S. Kaleta Office of the General Counsel US Dept. of Transportation Room 10428 400 Seventh St Washington, DC 20590 Dear Ms. Kaleta: I help maintain the public-domain tz database of time zone and daylight saving time transitions. This database contains code and data that represent the history of local time, and is used by many computers around the world. For details, please see <http://www.twinsun.com/tz/tz-link.htm>. Needless to say, we've been following the Indiana situation with interest. Deborah Goldsmith of Apple Computer, one of our correspondents, recently noted what appears to be a one-hour error in docket OST-2005-22114 <http://dmses.dot.gov/docimages/pdf95/382329_web.pdf>. Quoting from the first page of that document: DATES: The effective date of this rule is 2:00 a.m. EST Sunday, April 2, 2006, which is the changeover date from standard time to Daylight Saving Time. This cannot be exactly what was intended, because 2:00 a.m. EST corresponds to 1:00 a.m. CST, at which point clocks in the Central time zone will not spring forward for another hour. Therefore, as written, the rule requires that a clock in the affected area must jump backwards from 02:00 EST to 01:00 CST, and then an hour later jump ahead from 02:00 CST to 03:00 CDT. In other words, the currently-required clock transitions would look like this: 01:59:59 EST ... and then, one second later,... 01:00:00 CST ... ... ... and then, one hour later,... 01:59:59 CST ... and then, one second later,... 03:00:00 CDT We doubt whether you really intended that the citizens of Vincennes, Indiana should stay up in the middle of the night and change their clocks twice. Our correspondents have suggested two different ways out of this problem. First, and perhaps simplest, you could change the effective time of the rule from 2:00 a.m. EST to 3:00 a.m. EST. This will result in the following transition: 02:59:59 EST ... and then, one second later,... 03:00:00 CDT Second, if you prefer sticking to a 2:00 a.m. transition, you could append the following sentences: Counties that move from the Eastern to the Central Time Zone will switch directly from EST to CDT, so that their clocks need not change. From 2:00 a.m. CDT to 3:00 a.m. CDT these clocks will use CDT even though the rest of the Central Time Zone will still be using CST. This would result in the following transition: 01:59:59 EST ... and then, one second later,... 02:00:00 CDT Please let us know which solution (if any) you prefer, by writing to us in the time zone mailing list <tz(a)elsie.nci.nih.gov>. Thanks. Sincerely, Paul Eggert Computer Science Dept. 4532J Boelter Hall University of California Los Angeles, CA 90095-1596 +1 310 267 2254 (voice) eggert(a)ucla.edu (email)

1 0

RE: proposed tz patches for Indiana, New Brunswick, Gaza, etc.
by Paul Schauble Jan. 21, 2006

Jan. 21, 2006

I am inclined to think you should implement the letter of the law rather than guessing what DOT "really" meant. Either that or ask DOT for clarification. I hate to say it, but I've been involved in similar things that became a legal issue and the difference can matter. Unfortunately, this conflicts with the deadline. Maybe I'm a bit paranoid, but I'd ask. ++PLS -----Original Message----- From: tz-request(a)elsie.nci.nih.gov [mailto:tz-request@elsie.nci.nih.gov] On Behalf Of Deborah Goldsmith Sent: Friday, January 20, 2006 7:08 PM To: tz(a)lecserver.nci.nih.gov Subject: Re: proposed tz patches for Indiana, New Brunswick, Gaza, etc. On Jan 20, 2006, at 2:59 PM, Paul Eggert wrote: > + -5:00 - EST 2006 Apr 2 2:00 > + -6:00 US C%sT For all the Indiana counties that are switching from ET to CT, shouldn't this be: + -5:00 - EST 2006 Apr 2 2:00 + -5:00 - CDT 2006 Apr 2 3:00 + -6:00 US C%sT so that the time will proceed smoothly from 1:59:59 AM EST to 2:00:00 AM CDT, as proposed by Paul Eggert? With the rules the way they are now, the time will go from 1:59:59 AM EST to 1:00:00 AM CST, then from 1:59:59 AM CST to 3:00:00 AM CDT. Personally, I'm fine either way. Deborah

2 1