- tz - lists.iana.org

impending tzcode93b.tar.Z
by ado May 24, 1993

May 24, 1993

Having received useful changes from several sources, I'm hoping to put up tzcode93b.tar.Z for anonymous ftp soon. One thing I'd like to do is bring "strftime" up to date with new standards (akin to Arnold Robbins' version). A proposed "strftime" is attached; grepping for "5/24/93" will show up where changes have happened. Any comments would be appreciated; I'd particularly like word on the matter marked by "XXX" below. --ado #ifndef lint #ifndef NOID static char elsieid[] = "@(#)strftime.c 7.2"; /* ** Based on the UCB version whose ID appears below. ** This is ANSIish only when time is treated identically in all locales and ** when "multibyte character == plain character". */ #endif /* !defined NOID */ #endif /* !defined lint */ /* * Copyright (c) 1989 The Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms are permitted * provided that the above copyright notice and this paragraph are * duplicated in all such forms and that any documentation, * advertising materials, and other materials related to such * distribution and use acknowledge that the software was developed * by the University of California, Berkeley. The name of the * University may not be used to endorse or promote products derived * from this software without specific prior written permission. * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ #if defined(LIBC_SCCS) && !defined(lint) static char sccsid[] = "@(#)strftime.c 5.4 (Berkeley) 3/14/89"; #endif /* LIBC_SCCS and not lint */ #include "sys/types.h" #include "time.h" #include "tzfile.h" static char *afmt[] = { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", }; static char *Afmt[] = { "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", }; static char *bfmt[] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec", }; static char *Bfmt[] = { "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December", }; static size_t gsize; static char *pt; static void _add(); static void _conv(); static void _fmt(); size_t strftime(s, maxsize, format, t) char *s; char *format; size_t maxsize; struct tm *t; { pt = s; gsize = maxsize; _fmt(format, t); if (gsize <= 0) return(0); *pt = '\0'; return(maxsize - gsize); } static void _fmt(format, t) register char *format; struct tm *t; { for (; *format; ++format) { if (*format == '%') { label: switch(*++format) { case '\0': --format; break; case 'A': if (t->tm_wday < 0 || t->tm_wday > 6) _add("?"); else _add(Afmt[t->tm_wday]); continue; case 'a': if (t->tm_wday < 0 || t->tm_wday > 6) _add("?"); else _add(afmt[t->tm_wday]); continue; case 'B': if (t->tm_mon < 0 || t->tm_mon > 11) _add("?"); else _add(Bfmt[t->tm_mon]); continue; case 'b': case 'h': if (t->tm_mon < 0 || t->tm_mon > 11) _add("?"); else _add(bfmt[t->tm_mon]); continue; case 'c': _fmt("%D %X", t); continue; case 'C': /* ** %C used to do a... ** _fmt("%a %b %e %X %Y", t); ** ...whereas now POSIX 1003.2 calls for ** something completely different. ** (ado, 5/24/93) */ _conv((t->tm_year + TM_YEAR_BASE) / 100, 2, '0'); continue; case 'D': case 'x': /* ** Version 3.0 of strftime from Arnold Robbins ** (arnold(a)skeeve.atl.ga.us) does the ** equivalent of... ** _fmt("%a %b %e %Y"); ** ...for %x; since the X3J11 C language ** standard calls for "date, using locale's ** date format," anything goes. Using just ** numbers (as here) makes Quakers happier. ** (ado, 5/24/93) */ _fmt("%m/%d/%y", t); continue; case 'd': _conv(t->tm_mday, 2, '0'); continue; case 'E': case 'O': /* ** POSIX locale extensions, a la ** Arnold Robbins' strftime version 3.0. ** The sequences ** %Ec %EC %Ex %Ey %EY ** %Od %oe %OH %OI %Om %OM ** %OS %Ou %OU %OV %Ow %OW %Oy ** are supposed to provide alternate ** representations. ** (ado, 5/24/93) */ goto label; case 'e': _conv(t->tm_mday, 2, ' '); continue; case 'H': _conv(t->tm_hour, 2, '0'); continue; case 'I': _conv(t->tm_hour % 12 ? t->tm_hour % 12 : 12, 2, '0'); continue; case 'j': _conv(t->tm_yday + 1, 3, '0'); continue; case 'k': /* ** This used to be... ** _conv(t->tm_hour % 12 ? ** t->tm_hour % 12 : 12, 2, ' '); ** ...and has been changed to the below to ** match SunOS 4.1.1 and Arnold Robbins' ** strftime version 3.0. That is, "%k" and ** "%l" have been swapped. ** (ado, 5/24/93) */ _conv(t->tm_hour, 2, ' '); continue; #ifdef KITCHEN_SINK case 'K': /* ** After all this time, still unclaimed! */ _add("kitchen sink"); continue; #endif /* defined KITCHEN_SINK */ case 'l': /* ** This used to be... ** _conv(t->tm_hour, 2, ' '); ** ...and has been changed to the below to ** match SunOS 4.1.1 and Arnold Robbin's ** strftime version 3.0. That is, "%k" and ** "%l" have been swapped. ** (ado, 5/24/93) */ _conv(t->tm_hour % 12 ? t->tm_hour % 12 : 12, 2, ' '); continue; case 'M': _conv(t->tm_min, 2, '0'); continue; case 'm': _conv(t->tm_mon + 1, 2, '0'); continue; case 'n': _add("\n"); continue; case 'p': _add(t->tm_hour >= 12 ? "PM" : "AM"); continue; case 'R': _fmt("%H:%M", t); continue; case 'r': _fmt("%I:%M:%S %p", t); continue; case 'S': _conv(t->tm_sec, 2, '0'); continue; case 'T': case 'X': _fmt("%H:%M:%S", t); continue; case 't': _add("\t"); continue; case 'U': _conv((t->tm_yday + 7 - t->tm_wday) / 7, 2, '0'); continue; case 'u': /* ** From Arnold Robbins' strftime version 3.0: ** "ISO 8601: Weekday as a decimal number ** [1 (Monday) - 7]" ** (ado, 5/24/93) */ _conv(((t->tm_wday == 0) ? 7 : t->tm_wday), 1, '0'); continue; case 'V': /* ** From Arnold Robbins' strftime version 3.0: ** "the week number of the year (the first ** Monday as the first day of week 1) as a ** decimal number (01-53). The method for ** determining the week number is as specified ** by ISO 8601 (to wit: if the week containing ** January 1 has four or more days in the new ** year, then it is week 1, otherwise it is ** week 53 of the previous year and the next ** week is week 1)." ** (ado, 5/24/93) */ /* ** XXX--If January 1 falls on a Friday, ** January 1-3 are part of week 53 of the ** previous year. By analogy, if January ** 1 falls on a Thursday, are December 29-31 ** of the PREVIOUS year part of week 1??? ** (ado 5/24/93) /* ** You are understood not to expect this. */ { register int i; i = (t->tm_yday + 10 - (t->tm_wday ? (t->tm_wday - 1) : 6)) / 7; _conv((i == 0) ? 53 : i, 2, '0'); } continue; case 'v': /* ** From Arnold Robbins' strftime version 3.0: ** "date as dd-bbb-YYYY" ** (ado, 5/24/93) */ _fmt("%e-%b-%Y"); continue; case 'W': _conv((t->tm_yday + 7 - (t->tm_wday ? (t->tm_wday - 1) : 6)) / 7, 2, '0'); continue; case 'w': _conv(t->tm_wday, 1, '0'); continue; case 'y': _conv((t->tm_year + TM_YEAR_BASE) % 100, 2, '0'); continue; case 'Y': _conv(t->tm_year + TM_YEAR_BASE, 4, '0'); continue; case 'Z': #ifdef TM_ZONE if (t->TM_ZONE) _add(t->TM_ZONE); else #endif /* defined TM_ZONE */ if (t->tm_isdst == 0 || t->tm_isdst == 1) { extern char * tzname[2]; _add(tzname[t->tm_isdst]); } else _add("?"); continue; case '%': /* * X311J/88-090 (4.12.3.5): if conversion char is * undefined, behavior is undefined. Print out the * character itself as printf(3) also does. */ default: break; } } if (gsize <= 0) return; *pt++ = *format; --gsize; } } static void _conv(n, digits, fill) int n, digits, fill; { static char buf[10]; register char *p; for (p = buf + sizeof(buf) - 2; n > 0 && p > buf; n /= 10, --digits) *p-- = n % 10 + '0'; while (p > buf && digits-- > 0) *p-- = fill; _add(++p); } static void _add(str) register char *str; { for (;; ++pt, --gsize) { if (gsize <= 0) return; if (!(*pt = *str++)) return; } }

1 0

A brief history of (and agenda for) time zone libraries
by eggert＠twinsun.com May 15, 1993

May 15, 1993

Summary: The GNU C library is derived from Arthur David Olson's 1989 time zone code, with extensive changes. The good news is that these changes improve the modularity of Olson's code; the bad news is that it is now hard to merge some of Olson's more recent improvements into the GNU C library. Despite the bad news, Olson's fixes and improvements should be merged into the GNU C library somehow. While we're on the subject, the Linux time zone code also comes from Olson's 1989 code, but has only few minor changes; it should be updated to the current edition of Olson's code. __________ Olson's 1989 code. The original timezone code was written by Arthur David Olson. This public domain code has a good reputation. Even the Posix standard comes as close as a standard can to saying ``This is good stuff -- check it out!''; see Posix 1003.1-1990 section B.8.1.1, lines 4195-4201. The most famous publication of Olson's code was in comp.sources.unix 18, 111-117 (19 April 1989) -- see ftp.uu.net:/usenet/comp.sources.unix/volume18/localtime3/*. GNU C Library. The GNU C Library (see prep.ai.mit.edu:pub/gnu/glibc-1.05.tar.z) is derived from Olson's 1989 code. Here are its changes: 1. Rewrite the Makefile to use GNU make and GNU libc standards. 2. Split localtime.c into several smaller, more modular files. These files are: __tzset.c gmtime.c mktime.c offtime.c tzfile.c tzset.c. Completely rewrite these files in the GNU style. 3. Add some time functions not in Olson's package, e.g. adjtime. 4. Update some of the New Zealand time zone rules. Linux. Linux's code for timezones (see tsx-11.mit.edu:pub/linux/sources/sbin/timesrc.tar.Z) is also derived from Olson's 1989 code, but it has only the following minor changes: 1. Rewrite the Makefile to meet Linux standards. 2. Add a few #includes, or change them from "" form to <> form. Olson's current edition. Arthur David Olson is still maintaining both the code and the corresponding timezone database (see elsie.nci.nih.gov:pub/tz*). The differences between Olson's 1989 code and his current edition are as follows: 1. Fix some minor Makefile portability problems. 2. Fix some bugs in the C code, and avoid some possible core dumps. 3. Bring the leap second database up-to-date through June 1993. 4. Update the time zone database for Israel, Australia (which is particularly wild and woolly -- they hold voter referendums to change the timezone rules!), New Zealand, Britain, Portugal, Starke County Indiana, Saskatchewan. Remove the nonexistent US Pacific Presidential Election Time, which caused some problems late last year on some West Coast Suns. The New Zealand updates are a superset of the GNU C library's updates. 5. Add a -y option to zic to specify a command that tests for arbitrary year types; this is used in some of the new time zone rules. Proposal. Olson's changes should be propagated into both Linux and the GNU C library. Linux should update to Olson's current edition; this should be a simple merge. By the way, the Linux code should also give credit to Olson instead of silently removing his README file; this will help prevent the current situation from recurring. The GNU C library changes fall into two categories: (A) changes to Olson's localtime.c, and (B) everything else. Merging (B) is easy, almost as easy as merging the Linux timezone code, and I've already submitted patches to the GNU C library developers to do this. Merging (A) is harder, since the GNU C library has split up localtime.c into lots of little pieces. The GNU C library changes generally improve Olson's code -- they make the module interfaces cleaner, and the code is easier to follow. Unfortunately, it is now hard to tell how to propagate Olson's localtime.c changes and improvements into the GNU C library. The best person to do this propagation is the person who split up localtime.c in the first place. Another possibility is for the GNU C library to switch to a version of localtime.c that is as close as possible to Olson's latest version; that might simplify future maintenance.

2 2

Re: A brief history of (and agenda for) time zone libraries
by ado May 15, 1993

May 15, 1993

Improvidently, a couple of things make buying back the GNU changes at this end difficult. One is not so bad. Since the GNU folks are clearly implementers (in the ANSI sense of the word), they're entitled to use names from the implementers' name space in their code; this means that strictly internal functions can be split into separate source files without polluting the user's name space. It's not clear that this is kosher when the timezone package is distributed independently. But some care in packaging and some creative use of the preprocessor would avoid most challenges here. One is not so tractable. Buying back the GNU code at this point would also involve putting things under the GPL, which I'm loathe to do. --ado

1 0

Re: A brief history of (and agenda for) time zone libraries
by ado May 15, 1993

May 15, 1993

> From roland(a)gnu.ai.mit.edu Sat May 15 18:14:48 1993 > Return-Path: <roland(a)gnu.ai.mit.edu> > Received: from churchy.gnu.ai.mit.edu by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA22472; Sat, 15 May 93 18:14:34 EDT > Received: by churchy.gnu.ai.mit.edu (5.65/4.0) > id <AA21556(a)churchy.gnu.ai.mit.edu>; Sat, 15 May 93 18:14:01 -0400 > Date: Sat, 15 May 93 18:14:01 -0400 > From: roland(a)gnu.ai.mit.edu (Roland McGrath) > Message-Id: <9305152214.AA21556(a)churchy.gnu.ai.mit.edu> > To: eggert(a)twinsun.com > Cc: libc-alpha(a)gnu.ai.mit.edu, tz(a)elsie.nci.nih.gov > Subject: Re: A brief history of (and agenda for) time zone libraries > In-Reply-To: Paul Eggert's message of Sat, 15 May 93 00:08:44 PDT <9305150708.AA18312(a)bi.twinsun.com> > X-Shopping-List: (1) Hot mutant holidays > (2) Apologetic interruptions > (3) Frenetic lesions > > > Olson's 1989 code. > > > > The original timezone code was written by Arthur David Olson. This public > > domain code has a good reputation. Even the Posix standard comes as close as > > a standard can to saying ``This is good stuff -- check it out!''; see Posix > > 1003.1-1990 section B.8.1.1, lines 4195-4201. The most famous publication of > > Olson's code was in comp.sources.unix 18, 111-117 (19 April 1989) -- see > > ftp.uu.net:/usenet/comp.sources.unix/volume18/localtime3/*. > > I wish I had known that this code was being maintained, and where to get it > from, before now. > > > Proposal. > > > > Olson's changes should be propagated into both Linux and the GNU C library. > > Indeed. Linux is not my concern, but I plan to update glibc today. > > > The GNU C library changes fall into two categories: (A) changes to > > Olson's localtime.c, and (B) everything else. Merging (B) is easy, > > almost as easy as merging the Linux timezone code, and I've already > > submitted patches to the GNU C library developers to do this. Merging > > (A) is harder, since the GNU C library has split up localtime.c into lots > > of little pieces. The GNU C library changes generally improve Olson's > > code -- they make the module interfaces cleaner, and the code is easier > > to follow. > > These issues are very important to the GNU project, and to me. > > > Unfortunately, it is now hard to tell how to propagate Olson's > > localtime.c changes and improvements into the GNU C library. The best > > person to do this propagation is the person who split up localtime.c in > > the first place. > > I am that person, and I plan to do the work. > > > Another possibility is for the GNU C library to switch to a version of > > localtime.c that is as close as possible to Olson's latest version; that > > might simplify future maintenance. > > I really don't want to do this. It took me quite a while to untangle the > spaghetti in the first place. This would certainly not simplify > maintenance of the glibc code; it would return it to the obfuscated > spaghetti I started with. Having the code be modular and clean simplifies > maintenance for me. Using code close Olsen's code only simplifies future > merging with Olsen's code. >

1 0

proactive DST discovery?
by ado May 13, 1993

May 13, 1993

If you have insights on the advisability of doing network polling to learn of time changes, or have notions on how it might best be done, I'd appreciate your sharing them with tz(a)elsie.nci.nih.gov. -- Arthur David Olson ado(a)elsie.nci.nih.gov ADO and Elsie are Ampex and Borden trademarks "REM AND STINPY"--found in Bill Gates' startup file

1 0

Daylight savings time
by Monty Solomon May 3, 1993

May 3, 1993

An associate is looking for a source of information regarding the rules for daylight savings time in different countries. He has the North American rules but needs to find a source for Europe, etc. Do other countries observe daylight savings? Thanks. Monty --- # Monty Solomon / PO Box 2486 / Framingham, MA 01701-0405 # monty%roscom(a)think.com

1 0

Re: tzload memory leak?
by Joel.Tornatore＠Eng.Sun.COM April 23, 1993

April 23, 1993

Stephen, I have been out the for the last week (since 4/16, as a matter of fact.....Santa Fe was great!) so if this problem has not been resolved, please let me know. The problem was noticed in Solaris 2.0, and fixed in a patch to SunOS 4.1.3. You will also notice that the tzfile being used is opened and read for each call to tzset(), and the memory was not being freed. I can get you a new libc if necessary. joel > From eubank(a)predict.com Fri Apr 16 16:58 PDT 1993 > To: tz(a)elsie.nci.nih.gov > Subject: tzload memory leak? > > I've been using an application (under SunOS 4.1.3) > which switches time zones frequently. > It has a memory leak which I think I've tracked down to tzload, > which I call via tzset. Since it would hardly be noticeable to anyone > who didn't happen to be using (or abusing) tzset thousands of times, > I wouldn't be surprised if it hadn't been noticed before. On the off > chance that someone out there has encountered it, can you send me > pointers to patches, workarounds, etc.? I can't switch to Solaris yet. > > Here are some details: > I profile this code: > > #include <time.h> > > main() > { > int i; > for (i=0; i<100; i++) { > tzset(); > } > } > > > and find that malloc is called roughly 400 times, while free is called > roughly 300 times. If I increase the number of iterations in the loop > tp 1000, the calls to malloc and free go up by a factor of 10. malloc is > being called from calloc, which is being called from allocall, which is > being called from tzload. It looks to me like tzload allocates 4 things > and only frees 3 of them each time it is called. > > Thanks for any help you can give me. > > Stephen Eubank > eubank(a)predict.com >

1 0

Re: tzload memory leak?
by guy＠auspex.com April 17, 1993

April 17, 1993

> It has a memory leak which I think I've tracked down to tzload, > which I call via tzset. The data that's mallocated by the time zone stuff in SunOS 4.x is: the array of transition times; the array of information about the State Of The Time Zone after a given transition time (offset from GMT, DST or not, index into the list of time zone abbreviation strings, etc.); the array of time zone types (indices into the array of information about the State Of The Time Zone after a given transition time); the array of "char"s that contains the aforementioned abbreviation strings. Applications can't get a pointer to any of the first three items, so they can be freed whenever "tzset()" is called. However, it appears that the array containing abbreviation strings isn't freed because, according to the comment, it "might have other references to it", presumably obtained by using the "tzname[]" array (in the SV environment) or by using the "tm_zone" member of "struct tm". Now, from the way I read POSIX 1003.1, it neither commits to pointers fetched from "tzname[]" remaining valid after a call to "tzset()", nor explicitly claims that one should *not* assume they'll still point somewhere valid. The "ctime" manual page *does*, however, explicitly note that calls to "tzset()" or "tzsetwall()" overwrite the array to which the "tm_zone" field points. So I'm not sure what provoked somebody to make "tzset()" *not* free up the abbreviation-strings array - which is kind of annoying, given that I'd be willing to bet I'm the person who made it not do so, and seem to remember having done so because some stupid piece of software broke when it *did* free it.... Unfortunately, the pointer to that array is in a structure pointed to by a static pointer. However, *if* you can call "localtime()" on a time that's known to be in a time zone that corresponds to the first abbreviation in the file - possibly easier said than done, although you might try passing it first a pointer to a value of -1, and then a pointer to a value of "-1 plus half a year", and then, for each of the times, if "localtime()" doesn't return a null pointer, save the "tm_zone" values and, if both of them are non-NULL, see which one is lower - you can try doing a "free()" on the "tm_zone" value for that time zone. This is a somewhat disgusting hack, but, well, that's life....

1 0

tzload memory leak?
by eubank＠predict.com April 16, 1993

April 16, 1993

I've been using an application (under SunOS 4.1.3) which switches time zones frequently. It has a memory leak which I think I've tracked down to tzload, which I call via tzset. Since it would hardly be noticeable to anyone who didn't happen to be using (or abusing) tzset thousands of times, I wouldn't be surprised if it hadn't been noticed before. On the off chance that someone out there has encountered it, can you send me pointers to patches, workarounds, etc.? I can't switch to Solaris yet. Here are some details: I profile this code: #include <time.h> main() { int i; for (i=0; i<100; i++) { tzset(); } } and find that malloc is called roughly 400 times, while free is called roughly 300 times. If I increase the number of iterations in the loop tp 1000, the calls to malloc and free go up by a factor of 10. malloc is being called from calloc, which is being called from allocall, which is being called from tzload. It looks to me like tzload allocates 4 things and only frees 3 of them each time it is called. Thanks for any help you can give me. Stephen Eubank eubank(a)predict.com

1 0

FYA
by guy＠auspex.com April 6, 1993

April 6, 1993

Yes, but whose code is it using? :-) From: knauer(a)cs.uiuc.edu (Rob Knauerhase) Newsgroups: rec.humor.funny Subject: Daylight Savings Keywords: topical, smirk Message-ID: <S530.605b(a)looking.on.ca> Date: 6 Apr 93 07:20:02 GMT Organization: Department of Computer Science, Univ. of Illinois @ Urbana My mother didn't know just how smart her new VCR was until she got up this morning and noticed it was flashing: 1:00 1:00 1:00 1:00 1:00... Rob -- Rob Knauerhase, University of Illinois @ Urbana, Dept. of Computer Science "See, when the GOVERNMENT spends money, it creates jobs; whereas when the money is left in the hands of TAXPAYERS, God only knows what they do with it. Bake it into pies, probably. Anything to avoid creating jobs." -- Dave Barry -- Selected by Maddi Hausmann. MAIL your joke (jokes ONLY) to funny(a)clarinet.com. Attribute the joke's source if at all possible. A Daemon will auto-reply. Remember: Only ONE joke per submission. Extra jokes may be rejected.

1 0

Re: CORRECTION: April 18 in CM of OW3
by guy＠auspex.com March 29, 1993

March 29, 1993

> As a matter of fact, this year, summer time in Israel starts at 3-Apr-93 > till 4-Sep-93. Every year the dates of summer time are decided at that > year and cannot be anticipated. I.e., either Ephraim Silverberg, who contributed the most-recently-seen rules for Israel, as seen in "/usr/share/lib/zoneinfo/asia" in SunOS 4.x and 5.x systems and elsewhere: # From Ephraim Silverberg (April 18, 1989): # Prior to 1989, the rules concerning Daylight Savings Time changed every # year; as information, regarding exact times and dates during this period, # is not readily available at the present time, the rules commence starting # with the year 1989. # From 1989 onwards the rules are as follows: # # 1. Daylight Savings Time commences midnight of the first Saturday night # following the seven-day festival of Pesach (Passover). The transition # is from midnight Israel Standard Time to 1 a.m. Israel Daylight Savings # time. As the Pesach festival is dependent on the Lunar calendar (the # first day is always on the 15th day of the month of Nisan), the rule # changes every year on the Gregorian calendar. # # 2. Standard Time is reinstated on the Saturday night whereupon Jews # following the Ashkenazi (European) rite begin to recite the Selichot # (forgiveness) prayers prior to the Jewish Lunar New Year. The transition # is from midnight Israel Daylight Savings time to 11 p.m. Israel Standard # Time. The law (according to the Ashkenazi custom) concerning the # commencement of the Selichot prayers is described in chapter 128, section # 5 of the "Code of Jewish Law," by Rabbi Shlomo Ganzfried (translated by # Hyman E. Goldin): # # Beginning with the Sunday [**] before Rosh Hashanah [***], # we rise early for the service of Selichot (supplications for # forgiveness). If Rosh Hashanah occurs on Monday or Tuesday, we # begin saying the Selichot from the Sunday of the preceding week. # # This, too, varies from year to year on the Gregorian calendar and, thus, # two explicit timezone rules are required for each Gregorian year. # # [**] actually Saturday night as the Jewish day commences at nightfall. # [***] the Jewish Lunar New Year. was mistaken, or, after he sent that information out, the government went back to changing the rules every year? (Please "Cc:" "tz(a)elsie.nci.nih.gov" on any responses.)

1 0

Re: CORRECTION: April 18 in CM of OW3
by guy＠auspex.com March 29, 1993

March 29, 1993

>A week ago I asked: > >>Calendar Manager on Open window 3 has a bug. April 18 cannot be scheduled. >>Try it on your machine and return to me if you find a way to overcome it. > >Thank you all for your answers in which you said that such a problem >doe's not exist on your machine. Well, the problem found in file: > >/usr/share/lib/zoneinfo/asia > >April 18, 1993 was one line in that file which indicates the day of >summer time in Israel. > >Rule Zion 1993 only - Apr 18 00:00 1:00 D > >This line was fixed to: > >Rule Zion 1993 only - Apr 1 23:00 1:00 D > > >and after running 'zic asia', the problem disappear. > >Thanks > >-- > /\/\/\ E-mail: joel(a)mcil.comm.mot.com [ Motorola Communications Israel ] >/ Joel \ X.400 CJN003 [ Fixed & Data Products Division ] >\ Nahum/ Phone: +972 (3) 565-8479 [ 3 Kremenetski Street ] > \____/ Fax: +972 (3) 565-8356 [ 61 250 Tel-Aviv, ISRAEL ] Are you saying that Summer Time begins on April 1, not April 18, this year? If so, it'd cause problems with more than *just* the Calendar Manager, as the compiled time-zone files are used throughout the system. Are there any other errors in the rules for Israel in the "asia" file? We (the Timezone Cabal) would like to have the data in all the files be as correct as possible, so please send us any corrections you have.... (Timezone Caballeros: Should I post a followup and/or a note to "comp.sys.sun.admin" and possibly also "comp.unix.bsd" and "comp.unix.sys5.r4", requesting that *all* fixes to the timezone files be sent to "tz(a)elsie.nci.nih.gov"?)

1 0

Leap second announcement; updated "leapsecond" file
by ado Feb. 2, 1993

Feb. 2, 1993

A leap second announcement from the USNO is attached; as well as a shar-format version of an updated "leapseconds" file. You'll now find "tzdata93b.tar.Z" on elsie.nci.nih.gov; the only change to it from "tzdata93.tar.Z" is the updated "leapseconds" file. --ado > From ntp-relay(a)ni.umd.edu Tue Feb 2 14:49:18 1993 > Return-Path: <ntp-relay(a)ni.umd.edu> > Received: from ni.umd.edu by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA02852; Tue, 2 Feb 93 14:49:14 EST > Received: by ni.umd.edu id AA06039 > (5.65c/IDA-1.4.4 for ntp-list); Tue, 2 Feb 1993 14:21:15 -0500 > Received: from unbmvs1.csd.unb.ca by ni.umd.edu with SMTP id AA06030 > (5.65c/IDA-1.4.4 for <NTP(a)NI.UMD.EDU>); Tue, 2 Feb 1993 14:20:50 -0500 > Received: from unbmvs1.csd.unb.ca by UNBMVS1.csd.unb.ca (IBM MVS SMTP V2R1) > with BSMTP id 3951; Tue, 02 Feb 93 15:20:05 AST > Received: by UNBMVS1 (Mailer 15.14) id 5634; Tue, 02 Feb 93 15:18:57 AST > Date: Tue, 02 Feb 93 15:18:57 AST > From: LANG(a)unb.ca > To: "NTP List" <NTP(a)NI.UMD.EDU> > Subject: Leap Second Announcement from USNO > Message-Id: <ID3951.D930202.T151859.LANG(a)unb.ca> > Status: R > > > -------------------- Start of forwarded message -------------------- > Received: from UNBMVS1(MAILER) by UNBMVS1(Mailer 15.14) id 3871 > for LANG@UNBMVS1; Tue, 02 Feb 93 15:11:45 AST > Received: by UNBMVS1 (Mailer 15.14) id 2636; Tue, 02 Feb 93 15:09:43 AST > Date: Tue, 02 Feb 93 15:09:43 AST > From: <CANSPACE(a)UNB.CA> > To: <lang@UNBMVS1> > Received: from unb.ca by UNBMVS1.csd.unb.ca (IBM MVS SMTP V2R1) with TCP; > Tue, 02 Feb 93 15:08:16 AST > Received: from by unb.ca (4.1/SMI-4.1-921218.08:05) > id AZ01277; Tue, 2 Feb 93 15:08:27 AST > Received: from NEPTUNE.CSD.UNB.CA by NEPTUNE.CSD.UNB.CA (IBM VM SMTP V2R1) > with BSMTP id 5064; Tue, 02 Feb 93 15:03:20 AST > Received: from UNBVM1.BITNET (NJE origin LISTSERV@UNBVM1) by NEPTUNE.CSD.UNB.CA > (LMail V1.1b/1.7e) with BSMTP id 5057; Tue, 2 Feb 1993 14:58:41 -0400 > Comments: Original-Date: Tue, 2 Feb 1993 14:54:47 AST > X-Reply-To: Richard Langley <lang(a)JUPITER.SUN.CSD.UNB.CA> > X-Sender: Canadian Space Geodesy Forum <CANSPACE(a)UNBVM1.BITNET> > X-From: Richard Langley <lang(a)JUPITER.SUN.CSD.UNB.CA> > Subject: Leap Second Announcement from USNO > X-To: CANSPACE(a)unb.ca > X-To: Multiple recipients of list CANSPACE <CANSPACE(a)UNBVM1.BITNET> > Sender: <CANSPACE(a)UNB.CA> > Message-ID: <ID3871.D930202.T150943.CANSPACE(a)UNB.CA> > > File SER14 -- <930201.1735> > > > > U.S. NAVAL OBSERVATORY > WASHINGTON, DC 20392-5420 > > February 1, 1993 > No. 55 > > TIME SERVICE ANNOUNCEMENT SERIES 14 > > UTC TIME STEP > > 1. The International Earth Rotation Service (IERS) has announced the > Introduction of a time step to occur at the end of June 1993. > > 2. Coordinated Universal Time (UTC) will be retarded by 1.0s so that the > sequence of dates of the UTC markers will be: > > 1993 June 30 23h 59m 59s > 1993 June 30 23h 59m 60s > 1993 July 01 0h 0m 0s > > 3. The difference between UTC and International Atomic Time TAI is: > > from 1992 Jul 1, 0h UTC, to 1993 Jul.1, 0h UTC: TAI-UTC = +27s > from 1993 Jul 1, 0h UTC, until further notice: TAI-UTC = +28s > > 4. The insertion of one leap second will be evident by the change of > sign of the DUT1 correction which will become positive. Extrapolated > values of DUT1 are distributed weekly in the IERS Bulletin A (Time > Service Announcement Series 7). > > 5. All coordinated time scales will be affected by this adjustment. > However, the Loran-C, GPS and OMEGA systems will not be adjusted > physically. Tables of Coincidence (Time Service Announcement Series 9) > will be issued for Loran-C. For GPS, the leap second correction > contained within the UTC data of subframe 4, page 18 of the navigation > message transmitted by the satellite will change. > > Before the leap second > > GPS-UTC = +8s (i.e., GPS is ahead of UTC by eight seconds). > > After the leap second > > GPS-UTC = +9s (i.e., GPS will be ahead of UTC by nine seconds). > > The OMEGA Reference Ephoch (ORE) will change - that is, from 1 July > 1993 (after the leap second) the OMEGA system will operate with the > the beginning of segment one on seconds 42, 52, 02, 12, 22, and 32 of > each minute. > > GERNOT M. R. WINKLER > Director > Time Service Department > > via: > ============================================================================== > Richard B. Langley Internet: LANG(a)UNB.CA or SE(a)UNB.CA > Geodetic Research Laboratory BITnet: LANG@UNB or SE@UNB > Dept. of Surveying Engineering Phone: (506) 453-5142 > University of New Brunswick FAX: (506) 453-4943 > Fredericton, N.B., Canada E3B 5A3 Telex: 014-46202 > ============================================================================== > --------------------- End of forwarded message --------------------- : To unbundle, sh this file echo file 'leapseconds' >&2 cat >'leapseconds' <<'End of leapseconds' # @(#)leapseconds 7.6 # Allowance for leapseconds added to each timezone file. # The International Earth Rotation Service periodically uses leap seconds # to keep UTC to within 0.9 s of TAI (atomic time); see # Terry J Quinn, The BIPM and the accurate measure of time, # Proc IEEE 79, 7 (July 1991), 894-905. # There were no leap seconds before 1972, because the official mechanism # accounting for the discrepancy between atomic time and the earth's rotation # did not exist until the early 1970s. # The correction (+ or -) is made at the given time, so lines # will typically look like: # Leap YEAR MON DAY 23:59:60 + R/S # or # Leap YEAR MON DAY 23:59:59 - R/S # If the leapsecond is Rolling (R) the given time is local time # If the leapsecond is Stationary (S) the given time is GMT # Leap YEAR MONTH DAY HH:MM:SS CORR R/S Leap 1972 Jun 30 23:59:60 + S Leap 1972 Dec 31 23:59:60 + S Leap 1973 Dec 31 23:59:60 + S Leap 1974 Dec 31 23:59:60 + S Leap 1975 Dec 31 23:59:60 + S Leap 1976 Dec 31 23:59:60 + S Leap 1977 Dec 31 23:59:60 + S Leap 1978 Dec 31 23:59:60 + S Leap 1979 Dec 31 23:59:60 + S Leap 1981 Jun 30 23:59:60 + S Leap 1982 Jun 30 23:59:60 + S Leap 1983 Jun 30 23:59:60 + S Leap 1985 Jun 30 23:59:60 + S Leap 1987 Dec 31 23:59:60 + S Leap 1989 Dec 31 23:59:60 + S Leap 1990 Dec 31 23:59:60 + S Leap 1992 Jun 30 23:59:60 + S Leap 1993 Jun 30 23:59:60 + S End of leapseconds exit

1 0

End of Rio hiccup
by ado Feb. 2, 1993

Feb. 2, 1993

Again forwarded from comp.protocols.time.ntp. Since the article does not report just when the mayor turned the watch back, I'll forego making a Hawaii-style change to the southamerica file. --ado > From emv(a)msen.com Tue Feb 2 12:43:49 1993 > Path: nih-csl!darwin.sura.net!paladin.american.edu!howland.reston.ans.net!usc!sdd.hp.com!nigel.msen.com!emv > From: emv(a)msen.com (Edward Vielmetti) > Newsgroups: comp.protocols.time.ntp > Subject: Re: [brazil-time] rio de janeiro asks 'what time is it ?' > Message-ID: <1kmbt3INN36j(a)nigel.msen.com> > Date: 2 Feb 93 17:43:49 GMT > References: <1kkdseINNn87(a)nigel.msen.com> > Distribution: inet > Organization: Msen, Inc. -- Ann Arbor, Michigan > Lines: 29 > NNTP-Posting-Host: garnet.msen.com > X-Newsreader: TIN [version 1.1 PL8] > > Edward Vielmetti (emv(a)msen.com) wrote: > : Clock watchers take note... > > Ah, the time crisis in Brazil has passed (this also from REUTER). > > AM-BRAZIL-TIME 1STLD > RIO MAYOR RELUCTANTLY GIVES UP EXTRA HOUR OF DAYLIGHT > > (Eds: updates) > RIO DE JANEIRO, Brazil, Reuter - The mayor of Rio has > reluctantly agreed to set the city's clocks back one hour, > ending his defiance of a federal regulation to end summer > daylight saving time. > Mayor Cesar Maia turned his own watch back one hour Monday > after meeting Brazilian President Itamar Franco. > ``Now the Rio mayor and the president's watches are set for > the same time,'' Maia said. > He had ordered city workers to continue on the summer > schedule until Feb. 28, saying Rio's tourist industry needed the > extra hour of daylight. > But Rio banks, businesses, airports, bus stations, stock > market and major companies operated by the federal government's > time -- three hours behind Greenwich Mean Time-- causing great > confusion. > REUTER > > Edward Vielmetti, vice president for research, Msen Inc. emv(a)Msen.com > Msen Inc., 628 Brooks, Ann Arbor MI 48103 +1 313 998 4562 (fax: 998 4563)

1 0

Local time hiccup in Brazil
by ado Feb. 2, 1993

Feb. 2, 1993

The attached from comp.protocols.time.ntp. --ado > From emv(a)msen.com Mon Feb 1 19:05:20 1993 > Path: nih-csl!darwin.sura.net!newsserver.jvnc.net!yale.edu!nigel.msen.com!emv > From: emv(a)msen.com (Edward Vielmetti) > Newsgroups: comp.protocols.time.ntp > Subject: [brazil-time] rio de janeiro asks 'what time is it ?' > Message-ID: <1kkdseINNn87(a)nigel.msen.com> > Date: 2 Feb 93 00:05:20 GMT > Distribution: inet > Organization: Msen, Inc. -- Ann Arbor, Michigan > Lines: 50 > NNTP-Posting-Host: garnet.msen.com > X-Newsreader: TIN [version 1.1 PL8] > > Clock watchers take note... > > [ Article crossposted from msen.reuters.international ] > [ Posted on 1 Feb 1993 13:50:34 -0500 ] > > AM-BRAZIL-TIME > RIO DE JANEIRO ASKS 'WHAT TIME IS IT ?' > > RIO DE JANEIRO, Brazil, Reuter - Residents of Rio de Janeiro > woke up Monday wondering what time it is. > The confusing clock situation arose when Rio Mayor Cesar > Maia defied a Brazilian government regulation to end summer's > daylight savings time Sunday and turn the clocks back an hour. > But Maia, saying Rio's tourism industry needs the extra hour > of daylight that daylight savings time provides, said the city > government and everyone and everything associated with it would > stick with the summertime time schedule until Feb. 28. > ``I am not going to turn my clock back, nor will the clocks > controlled by the city be turned back,'' Maia was quoted as > saying in the Jornal do Brasil newspaper Sunday. > Rio's banks, most businesses, airports, bus stations and the > stock market are abiding by the federal government's time. > Maia said Rio de Janeiro's tourism industry would be hurt by > moving the clocks back in the middle of the Southern > Hemisphere's summer. > ``The mayor said the jobs of 30,000 people depend on this > extra hour of sunlight, when residents and tourists stay on the > streets and beaches spending money and having fun,'' the > spokesman said. > Maia's decree, which does not apply to the city's suburbs, > has left most residents wondering whether they should begin > wearing two watches. > A spokeswoman for the business owners association said Rio > stores and shopping centers were using standard time on Monday, > but it was still not clear what they would do on Tuesday. > ``The official schedule in Rio is the national standard > time. The decree does not impose the summer schedule, but rather > suggests that businesses, services and industry operate on > summer's time,'' said the mayor's spokesman, adding that Rio's > public clocks will be reset to national standard time. > Maia was to meet President Itamar Franco later Monday to > discuss the time situation, among other things. > At least for the meeting, the mayor will have to think > standard time. The meeting is scheduled for 3:30 p.m. federal > government time, the spokesman said. > REUTER > > Edward Vielmetti, vice president for research, Msen Inc. emv(a)Msen.com > Msen Inc., 628 Brooks, Ann Arbor MI 48103 +1 313 998 4562 (fax: 998 4563)

1 0

tzcode93.tar.Z and tzdata93.tar.Z
by ado Jan. 8, 1993

Jan. 8, 1993

A new version of the time zone stuff is available for anonymous ftp from elsie.nci.nih.gov (128.231.16.1), in the ~ftp/pub directory: -r--r--r-- 1 ado 91953 Jan 8 07:01 tzcode93.tar.Z -r--r--r-- 1 ado 44313 Jan 8 07:01 tzdata93.tar.Z At kre's suggestion, the package has been split in two--a code piece (which also includes documentation) that's only of use to folks who want to recompile things and a data piece useful to anyone who can run "zic". The new version has a few changes to the data files, a few portability changes, and an off-by-one fix (with thanks to Tom-Karzes(a)deshaw.com for providing a description and a solution). --ado

1 0

elsie.nci.nih.gov:~ftp/pub/tz92c.tar.Z
by ado Nov. 22, 1992

Nov. 22, 1992

The fallout from the latest round of DST transitions is available as elsie.nci.nih.gov:~ftp/pub/tz92c.tar.Z There are changes for Portugal, Saskatchewan, and "Pacific-New"; there's also a change to "zic.c" that makes it portable to more systems. Any ideas for how to handle things are welcome; they are best mailed to tz(a)elsie.nci.nih.gov so that they can get wide consideration. --ado

2 1

Re:East-Saskatchewan -> Saskatchewan [forwarded with permission]
by ado Nov. 6, 1992

Nov. 6, 1992

> Date: 06 Nov 1992 16:13:04 -0600 (CST) > From: jones(a)skdad.usask.ca (W. Jones) > Subject: Re: East-Saskatchewan -> Saskatchewan > To: ado(a)elsie.nci.nih.gov > Cc: eggert(a)twinsun.com, hardie(a)herald.usask.ca, henry(a)zoo.utoronto.ca, > peachey(a)pixar.com, tastad(a)sklib.usask.ca > ... > > Earlier I wrote: > >The most likely answer is that no-DST was adopted province-wide on some date > >(say in the late 1960s), and before that was subject to community variations. > >One thing I might ask is what precision you consider important for describing > >earlier practice. (Whatever the date, there were certainly no Unix systems > >running in affected areas.) > > The approximate answer below is based on information I got from our law > library, the provincial archives, and the provincial Community Services > department. A precise history would require digging through newspaper > archives, and since you didn't say what you wanted, I didn't bother. > > Saskatchewan is split by a time zone meridian (105W) and over the years > the boundary became pretty ragged as communities near it reevaluated > their affiliations in one direction or the other. In 1965 a provincial > referendum favoured legislating common time practices. > > On 15 April 1966 the Time Act (c. T-14, Revised Statutes of Saskatchewan > 1978) was proclaimed, and established that the eastern part of > Saskatchewan would use CST year round, that districts in northwest > Saskatchewan would by default follow CST but could opt to follow Mountain > Time rules (thus 1 hour difference in the winter and zero in the summer), > and that districts in southwest Saskatchewan would by default follow > MT but could opt to follow CST. > > It took a few years for the dust to settle (I know one story of a town > on one time zone having its school in another, such that a mom had to > serve her family lunch in two shifts), but presently it seems that only > a few towns on the border with Alberta (e.g. Lloydminster) follow MT > rules any more; all other districts appear to have used CST year round > since sometime in the 1960s. > > Here's how I would summarize things. Establish a "Saskatchewan" CST time > zone, and note that it officially exists as of 15 April 1966. Any current > exceptions can put themselves in the "Mountain" zone, since those are the > rules they follow. Any past exceptions can be forgotten, since that's > what those who live here have done.

1 0

East-Saskatchewan -> Saskatchewan [forwarded with permission]
by ado Oct. 28, 1992

Oct. 28, 1992

> From: henry(a)zoo.toronto.edu > Date: Wed, 28 Oct 92 11:58:53 EST > Subject: Re: East-Saskatchewan -> Saskatchewan > To: ado(a)elsie.nci.nih.gov, eggert(a)twinsun.com > Cc: jones(a)skorpio.usask.ca (W. Jones), peachey(a)pixar.com > > >... Anyway, I agree with Darwyn that the situation since around the > >Unix epoch is CST year round for the whole province, not just some flakes > >in the eastern corner. > > Actually, I think the province *is* split, but it's not an eastern corner > vs. everybody else. I grew up in Saskatoon, which is roughly central (and > one of the two major cities), and as a kid (1960s) I never knew DST *existed*. > (DST still strikes me as strange and stupid, actually.) Saskatoon, and at > least the immediate vicinity, has been on CST year round for a long time. > > On the other hand, other areas of the province haven't been... I first > became aware of DST when visiting relatives in Fort Qu'Appelle, a small > town south and east of Saskatoon. That was mid-late 1960s. I haven't been > back there for a long time and don't know the current situation. > > Henry Spencer at U of Toronto Zoology > henry(a)zoo.toronto.edu utzoo!henry

1 0

East-Saskatchewan -> Saskatchewan [forwarded with permission]
by ado Oct. 28, 1992

Oct. 28, 1992

> Date: Tue, 27 Oct 92 15:40:24 PST > From: eggert(a)twinsun.com (Paul Eggert) > Message-Id: <9210272340.AA13750(a)farside.twinsun.com> > To: ado(a)elsie.nci.nih.gov > ... > Subject: East-Saskatchewan -> Saskatchewan > ... > W. Jones works in Saskatoon, which (according to my dictionary) is in Central > Saskatchewan. Assuming he's correct about the clocks in his immediate > neighborhood, at least the `East-' in `East-Saskatchewan' must be wrong. > Of your sources, Bur and Peachey (another Saskatchewan resident) agree with > Jones, whereas Devine disagrees. Given the current evidence, I'd tend to go > with Bur, Jones, and Peachey -- after all, two of them live there.

1 0

Historical material on Saskatchewan
by ado Oct. 28, 1992

Oct. 28, 1992

I've attached some historical material on the original of East-Sask. --ado > From seismo!mit-eddie!spock.ee.mcgill!mannix.decnet!burj Fri Mar 6 08:58:05 1987 > Received: by elsie.UUCP (5.51/4.7) > id AA13319; Fri, 6 Mar 87 08:57:48 EST > Received: by seismo.CSS.GOV (5.54/1.14) > id AA12469; Fri, 6 Mar 87 05:13:00 EST > Received: by harvard.harvard.edu; Fri, 6 Mar 87 05:13:14 EST > Received: by EDDIE.MIT.EDU (5.31/4.7) id AA25906; Fri, 6 Mar 87 05:12:12 EST > Received: from spock by musocs.cs.mcgill id aa00376; 6 Mar 87 4:40 EST > Received: from Mannix.UdeM (mannix.ARPA) by spock.EE.MCGILL (4.12) > id AA00684; Fri, 6 Mar 87 04:50:05 est > Date: Thu, 5 Mar 87 03:37:17 est > From: Justin Bur <seismo!harvard!spock.ee.mcgill!mannix.decnet!burj> > Message-Id: <8703050837.AA00977(a)Mannix.UdeM> > Poslfit: poslfit > To: musocs!tz%elsie.uucp > Subject: DST in Saskatchewan, Canada > > The province of Saskatchewan, normally in the Central time zone, > has not used daylight savings time for the past several years. > I think there was some talk of using it for the first time this > year, but I don't remember. I also don't know if DST has never > been used in Sask. or if it used to be used some time ago: my > source is the national radio schedules of the Canadian Broadcasting > Corporation, and my subscription started in 198?. I will send more > precise information if I can find it, but it would probably be best > to find a local source of information. I *think* sask.uucp is the > University of Saskatchewan; I don't have a uucp map handy. > > Justin Bur -- Universite de Montreal > <burj(a)iros1.uucp> seismo!think!mosart!mcgill-vision!iros1!burj > > From seismo!ihnp4!sask!skorpio.UUCP!peachey Mon Mar 16 21:59:53 1987 > Received: by elsie.UUCP (5.51/4.7) > id AA00162; Mon, 16 Mar 87 21:59:38 EST > Received: from cbosgd.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP > id AA13632; Mon, 16 Mar 87 17:31:56 EST > Received: by cbosgd.MIS.OH.ATT.COM (smail2.2) > id AA07856; 16 Mar 87 17:31:04 EST (Mon) > Received: by ihnp4.ATT.COM id AA03508; 16 Mar 87 15:10:26 CST (Mon) > Received: by sask.USask.UUCP (4.12/USask-2.01/9-Feb-87) > id AA24861; Mon, 16 Mar 87 15:03:37 cst > Received: by skorpio.USask.UUCP (4.12/USask-2.0/17-Dec-86) > id AA02480; Mon, 16 Mar 87 14:54:46 cst > Date: Mon, 16 Mar 87 14:54:46 cst > From: seismo!ihnp4!skorpio!peachey (Darwyn Peachey) > Message-Id: <8703162054.AA02480(a)skorpio.USask.UUCP> > To: elsie!tz > Subject: northamerica timezones & Saskatchewan > Cc: peachey > > > If I am reading your "northamerica" (version 3.1) timezone file correctly, > it appears to be inaccurate concerning the province of Saskatchewan in > Canada. You seem to assume that all of Canada observes the DST rules. > In fact, Saskatchewan is always on standard time and has been for several > years (up to 20, I'd guess). To be more precise, we are always on daylight > time, since we are geographically in the Mountain zone, but we use Central > Standard Time year round! Thus, there is always a four hour time difference > between us and Hawaii (whereas the temperature difference varies from > -130F to +20F). > > Darwyn Peachey peachey(a)sask.UUCP peacheyd(a)sask.BITNET (306) 966-4909 > > From seismo!nbires!vianet!devine Tue Mar 17 14:33:32 1987 > Received: by elsie.UUCP (5.51/4.7) > id AA03816; Tue, 17 Mar 87 14:33:18 EST > From: seismo!nbires!vianet!devine > Received: from nbires.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP > id AA14658; Tue, 17 Mar 87 12:36:49 EST > Date: Tue, 17 Mar 87 12:36:49 EST > Message-Id: <8703171736.AA14658(a)seismo.CSS.GOV> > To: elsie!tz > Subject: Re: northamerica timezones & Saskatchewan > Cc: devine > > Darwyn Peachey peachey(a)sask.UUCP writes: > > If I am reading your "northamerica" (version 3.1) timezone file correctly, > > it appears to be inaccurate concerning the province of Saskatchewan in > > Canada. You seem to assume that all of Canada observes the DST rules. > > In fact, Saskatchewan is always on standard time and has been for several > > years (up to 20, I'd guess). To be more precise, we are always on daylight > > time, since we are geographically in the Mountain zone, but we use Central > > Standard Time year round! > > The information I have found on Saskatchewan Daylight Time is this: > > 1962-1971 Variable (each locality may have done something different) > but it seems to be last Sunday in April to last Sunday > in October (September in 1960-1) > > 1972-present? Observed in entire province except in the far-eastern > part (that part is on Central Standard time all year) > The western part is on the last Sunday in April to > last Sunday in October schedule > > I don't know where the machine 'skorpio' is but I infer that it is in > the Eastern part of Saskatchewan. Does anyone have access to an official > publication of Canada that describes DST? Does such a publication exist? > > Bob Devine

1 0

East-Saskatchewan -> Saskatchewan [forwarded with permission]
by ado Oct. 28, 1992

Oct. 28, 1992

> Date: Tue, 27 Oct 92 13:38:07 PST > From: eggert(a)twinsun.com (Paul Eggert) > Message-Id: <9210272138.AA13450(a)farside.twinsun.com> > To: ado(a)ncifcrf.gov > Subject: East-Saskatchewan -> Saskatchewan [slightly revised patch] > > Here's a slightly revised patch for the East-Saskatchewan problem. The only > change to the previous patch is the last one -- the change to Mexico/General. > This version thus saves a bit of disk space, since Canada/Saskatchewan and > Mexico/General are identical. > > *** northamerica Thu Apr 23 10:34:33 1992 > --- northamerica.fix Tue Oct 27 13:32:04 1992 > *************** > *** 215,220 **** > --- 215,224 ---- > # be same as Pacific. Stick with rules posted in 1988 until more authoritative > # information is available. > > + # From W. Jones (October 27, 1992): > + # Since (I believe) around 1964, all of Saskatchewan is on CST year round, > + # by law [the U.S. Naval Observatory notwithstanding]. > + > # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S > Rule Canada 1969 max - Oct lastSun 2:00 0 S > Rule Canada 1969 1986 - Apr lastSun 2:00 1:00 D > *************** > *** 226,232 **** > Zone Canada/Atlantic -4:00 Canada A%sT > Zone Canada/Eastern -5:00 Canada E%sT > Zone Canada/Central -6:00 Canada C%sT > ! Zone Canada/East-Saskatchewan -6:00 - CST # No DST as of 1987 > Zone Canada/Mountain -7:00 Canada M%sT > Zone Canada/Pacific -8:00 Canada P%sT > Zone Canada/Yukon -9:00 Canada Y%sT > --- 230,236 ---- > Zone Canada/Atlantic -4:00 Canada A%sT > Zone Canada/Eastern -5:00 Canada E%sT > Zone Canada/Central -6:00 Canada C%sT > ! Zone Canada/Saskatchewan -6:00 - CST > Zone Canada/Mountain -7:00 Canada M%sT > Zone Canada/Pacific -8:00 Canada P%sT > Zone Canada/Yukon -9:00 Canada Y%sT > *************** > *** 290,296 **** > # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] > Zone Mexico/BajaNorte -8:00 Mexico P%sT > Zone Mexico/BajaSur -7:00 - MST > ! Zone Mexico/General -6:00 - CST > > ############################################################################### > > --- 294,300 ---- > # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] > Zone Mexico/BajaNorte -8:00 Mexico P%sT > Zone Mexico/BajaSur -7:00 - MST > ! Link Canada/Saskatchewan Mexico/General > > ###############################################################################

1 0

please remove US/Pacific-New [forwarded with permission]
by ado Oct. 28, 1992

Oct. 28, 1992

[My inclination would be to comment out the last two lines of the "pacificnew" file rather than making the changes indicated below, perhaps also adding a comment as to why they've been commented out. What do other folks feel? --ado] > Date: Tue, 27 Oct 92 13:09:45 PST > From: eggert(a)twinsun.com (Paul Eggert) > Message-Id: <9210272109.AA11863(a)farside.twinsun.com> > To: ado(a)ncifcrf.gov > Subject: please remove US/Pacific-New > > The following patch removes US/Pacific-New, which causes more problems than it > cures (as I described in yesterday's message). Also, remove the file > `pacificnew'. > > *** Makefile Thu Jul 9 12:51:31 1992 > --- Makefile.fix Tue Oct 27 13:08:11 1992 > *************** > *** 189,195 **** > MANS= newctime.3 newtzset.3 tzfile.5 zic.8 zdump.8 > DOCS= Patchlevel.h README Theory $(MANS) date.1 Makefile > YDATA= africa antarctica asia australasia \ > ! europe northamerica southamerica pacificnew etcetera factory > NDATA= systemv > SDATA= solar87 solar88 solar89 > TDATA= $(YDATA) $(NDATA) $(SDATA) > --- 189,195 ---- > MANS= newctime.3 newtzset.3 tzfile.5 zic.8 zdump.8 > DOCS= Patchlevel.h README Theory $(MANS) date.1 Makefile > YDATA= africa antarctica asia australasia \ > ! europe northamerica southamerica etcetera factory > NDATA= systemv > SDATA= solar87 solar88 solar89 > TDATA= $(YDATA) $(NDATA) $(SDATA) >

1 0

East-Saskatchewan -> Saskatchewan [forwarded with permission]
by ado Oct. 28, 1992

Oct. 28, 1992

> Date: Tue, 27 Oct 92 13:04:32 PST > From: eggert(a)twinsun.com (Paul Eggert) > Message-Id: <9210272104.AA11841(a)farside.twinsun.com> > To: ado(a)ncifcrf.gov > Subject: East-Saskatchewan -> Saskatchewan > > W. Jones <jones(a)skdad.usask.ca> writes that all of Saskatchewan is on CST year > round. I'll enclose his comments at the end of this message. So I propose > the following patch to the tz package: > > *** northamerica Thu Apr 23 10:34:33 1992 > --- northamerica.fix Tue Oct 27 12:58:38 1992 > *************** > *** 215,220 **** > --- 215,224 ---- > # be same as Pacific. Stick with rules posted in 1988 until more authoritative > # information is available. > > + # From W. Jones (October 27, 1992): > + # Since (I believe) around 1964, all of Saskatchewan is on CST year round, > + # by law [the U.S. Naval Observatory notwithstanding]. > + > # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S > Rule Canada 1969 max - Oct lastSun 2:00 0 S > Rule Canada 1969 1986 - Apr lastSun 2:00 1:00 D > *************** > *** 226,232 **** > Zone Canada/Atlantic -4:00 Canada A%sT > Zone Canada/Eastern -5:00 Canada E%sT > Zone Canada/Central -6:00 Canada C%sT > ! Zone Canada/East-Saskatchewan -6:00 - CST # No DST as of 1987 > Zone Canada/Mountain -7:00 Canada M%sT > Zone Canada/Pacific -8:00 Canada P%sT > Zone Canada/Yukon -9:00 Canada Y%sT > --- 230,236 ---- > Zone Canada/Atlantic -4:00 Canada A%sT > Zone Canada/Eastern -5:00 Canada E%sT > Zone Canada/Central -6:00 Canada C%sT > ! Zone Canada/Saskatchewan -6:00 - CST > Zone Canada/Mountain -7:00 Canada M%sT > Zone Canada/Pacific -8:00 Canada P%sT > Zone Canada/Yukon -9:00 Canada Y%sT > > > Here are Jones's comments: > > Date: Tue, 27 Oct 92 14:37:34 CST > From: jones(a)skdad.usask.ca (W. Jones) > To: eggert(a)twinsun.com > Cc: wright(a)sask.usask.ca > Organization: University of Saskatchewan, Saskatoon, Canada > > ... for this site, in order to follow local time correctly > requires choosing the ruleset named "East-Saskatchewan". Sounds > plausible, until you consider that the measure of places for which a > ruleset "Saskatchewan" or "West-Saskatchewan" applies is zero. > > How did this come about? Since (I believe) around 1964, all of > Saskatchewan is on CST year round, by law; but since that distinction > makes us rebels to North American convention, it tends to get left out of > discussions for simplicity. Thus when the timezone package appeared in > 1987, lo and behold we were lumped with the other Central places, as > implied in this table in the documentation: > > # From U. S. Naval Observatory (January 19, 1989): > # CANADA NEW FDL 3.5H BEHIND UTC ST.JOHN'S > # CANADA NEW FDL 1.5H BEHIND UTC APR 3 - OCT 29 > # CANADA ATLANTIC 4 H BEHIND UTC HALIFAX > # CANADA ATLANTIC 3 H BEHIND UTC APR 3 - OCT 29 > # CANADA EASTERN 5 H BEHIND UTC TORONTO, MONTREAL, OTTAWA > # CANADA EASTERN 4 H BEHIND UTC APR 3 - OCT 29 > # CANADA CENTRAL 6 H BEHIND UTC REGINA, WINNIPEG > # CANADA CENTRAL 5 H BEHIND UTC APR 3 - OCT 29 > # CANADA MOUNTAIN 7 H BEHIND UTC CALGARY, EDMONTON > # CANADA MOUNTAIN 6 H BEHIND UTC APR 3 - OCT 29 > # CANADA PACIFIC 8 H BEHIND UTC VANCOUVER > # CANADA PACIFIC 7 H BEHIND UTC APR 3 - OCT 29 > # CANADA YUKON SAME AS PACIFIC DAWSON > > I complained, and the eventual result was the adjustment below: > > # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] > # Bob Devine says that DST *is* observed in Newfoundland > Zone Canada/Newfoundland -3:30 Canada N%sT > Zone Canada/Atlantic -4:00 Canada A%sT > Zone Canada/Eastern -5:00 Canada E%sT > Zone Canada/Central -6:00 Canada C%sT > Zone Canada/East-Saskatchewan -6:00 - CST # No DST as of 1987 > Zone Canada/Mountain -7:00 Canada M%sT > Zone Canada/Pacific -8:00 Canada P%sT > > apparently the U.S. Naval Observatory was believed infallible, thus the > fellow from Saskatchewan must be following some kooky (and new) local > practice, thus we'll just throw him a sop....

1 0

US presidential election year politics help cause time zone bugs
by eggert＠twinsun.com Oct. 26, 1992

Oct. 26, 1992

Several people on the west coast of the US reported that their Unix systems failed to switch from daylight savings time to standard time yesterday, 26 October 1992. The reason? When they originally configured their systems, they were asked to choose one of the following time zone rules: US/Alaska US/Central US/Hawaii US/Pacific US/Aleutian US/East-Indiana US/Michigan US/Pacific-New US/Arizona US/Eastern US/Mountain US/Samoa ... Some people chose `US/Pacific-New' instead of `US/Pacific'. After all, who wants the old version when you can have the new version? Unfortunately, `US/Pacific-New' stands for ``Pacific Presidential Election Time'', which was passed by the House in April 1989 but never signed into law. In presidential election years, this rule would have delayed the PDT-to-PST switchover until after the election, to lessen the effect of broadcast news election projections on last-minute west-coast voters. Thus, US/Pacific-New and US/Pacific have always been identical -- until yesterday. This problem comes from combining Arthur David Olson's deservedly popular time zone software (which you can FTP from elsie.nci.nih.gov in pub/tz92b.tar.Z) with some overly terse vendor-supplied installation procedures. No doubt Olson did not use a more informative name like `US/Pacific-Presidential-Election' because of the 14-character file name length limit in many Unix file systems. In view of yesterday's experience, though, it seems unwise to make the hypothetical choice available under any name, since it gives free rein to Murphy's Law.

1 0