- tz - lists.iana.org

Re: time zone survey
by Dik.Winter＠cwi.nl June 11, 1993

June 11, 1993

> Attached are results from a casual time zone survey. An interesting survey. > I tossed out data with unzoned time stamps, data without a recognizable > domained system name in the Message-ID, and data from ".com" sites. Why did you toss out data from ".com" sites? > 1 +0530 > 1 Jun 93 15:30:55 +0530 imtech.ernet.in This might be a valid one. It is apparently from India which lives around +5 and +6. > 1 +0611 > Wed, 02 Jun 93 16:08:33 +0611 trashcan.hacktic.nl This one is definitely invalid. Most probably a PC hooked up to hacktic (a public access system in the Netherlands). Probably the owner did set it up wrong. > 1 +0730 > 6 Jun 1993 08:25:56 +0730 news.Colorado.EDU Ha! If even Colorado.Edu cannot get it correct! ;-). > MESZ Middle European Standard Zone Probably "Mittel Europ"aische Standard Zeit". > MEZ Middle European Zone (used primarily in Germany) "Mittel Europ"aische Zeit". And yes, primarily german speaking countries. > BSC ? > Tue, 25 May 1993 10:51:05 BSC FINHUTC.HUT.FI > Tue, 1 Jun 1993 11:57:00 BSC brfapesp.bitnet These two are definitely not in the same timezone. One is in Finland, one in Brazil. > TUR Turkey? Probably yes. All sites are in Turkey. > The results make me think there's little prospect of discovering useful > time zone information (in particular, time transitions that don't already > show up in tzdata93c.tar.Z) from running through news articles; someone > with an account on a site that does extensive archiving of news might prove > me wrong. I think there is no prospect at all. And it will grow worse. In the case of the "hacktic.nl" machine we see that we have a single machine that is configured wrong. I think more of this kind of machines will emerge. They do not care what time the system runs on, as long as it is internally consistent (and even that is not needed at all times). Time transitions especially will be a problem, and it will continue to be a problem. At our institute during the transition to DST all Suns (which use your package) switched on time, but all SGI's (using SysV's method) did not. The system administrator simply had forgotten to update the file that contained timezone information (/etc/TIMEZONE) and it took a few days before somebody noticed. (Yes, in SysV the file has to be changed every year again. And SGI shows no inclination to change.) So I think nobody will prove you wrong.

1 0

Re: "32 time zones"
by Amos Shapir June 9, 1993

June 9, 1993

> I don't know about any zones with > three-quarter hour offsets, but would like to know what they are. >From the same usno1989 file (which is outdated and contains errors, but seems to be the most comprehensive source we have): NEPAL 5H45M AHEAD OF UTC NEW ZEALAND 12H45M AHEAD OF UTC CHATHAM ISLAND In the Rand-McNally atlas there are a few other Pacific islands with 40 mins offsets, all of which appear as full or half-hour zones in the file; it also lists Nepal at GMT+5:40 and Liberia as -0:44 (yes, forty four) -- makes sense since Monrovia is at exactly 11 degrees west, but probably outdated too. Amos Shapir Net: amos(a)cs.huji.ac.il Paper: The Hebrew Univ. of Jerusalem, Dept. of Comp. Science. Givat-Ram, Jerusalem 91904, Israel Tel: +972 2 585706 GEO: 35 11 46 E / 31 46 21 N

2 1

"32 time zones"
by ado June 8, 1993

June 8, 1993

Our society has created a fictional time system of 32 time zones (24 one-hour offsets and several more half-hour and three-quarter hour offsets). --Tognazzini, Bruce (tog(a)eng.sun.com) "Tog on Interface: The Myth of Precision", Sun World, volume 6, number 7 (June, 1993), page 100. A grep in /usr/lib/zoneinfo/* on a SunOS 4.1.1 system failed to show up eight oddball time zones (see attached). Does anyone know of the origin for the "32" time zones? --ado

3 3

Re: "32 time zones"
by tog＠cloud9.Eng.Sun.COM June 8, 1993

June 8, 1993

Well, so much for my books are better than computers theory. Still and all, I can think of no atlas that would manage to tell one person there were 24 zones and another person there were 40 zones. We have a long way to go not only in information storage, but in responsive retrieval. -Tog > From amos(a)cs.huji.ac.il Tue Jun 8 07:02:26 1993 > To: ado(a)bossie.nci.nih.gov (Arthur David Olson) > Subject: Re: "32 time zones" > Cc: tog@Eng, tz(a)bossie.nci.nih.gov > Content-Length: 579 > X-Lines: 13 > > Well, you didn't grep hard enough; I just did: > > grep '[.H][0-9]' /usr/share/lib/zoneinfo/usno1989 > > And got 11 part-hour zones, 3 of which apply DST which can be also counted as > separate timezones; plus Russia's East Siberia zone which is 13 hours ahead of > GMT and 14 with DST. In total, we have 24+12+4 or 40 time zones, 36 of which > are in use somewhere at any given time. > > Amos Shapir Net: amos(a)cs.huji.ac.il > Paper: The Hebrew Univ. of Jerusalem, Dept. of Comp. Science. > Givat-Ram, Jerusalem 91904, Israel > Tel: +972 2 585706 GEO: 35 11 46 E / 31 46 21 N >

1 0

Re: "32 time zones"
by tog＠cloud9.Eng.Sun.COM June 8, 1993

June 8, 1993

Try any (printed) atlas. Or wait until the next century when computers just barely begin to catch up with where printed matter was 300 years ago. Grepping indeed! -Tog > From ado(a)bossie.nci.nih.gov Tue Jun 8 06:40:56 1993 > To: amos(a)cs.huji.ac.il, tog@Eng, tz(a)bossie.nci.nih.gov > Subject: "32 time zones" > Content-Length: 481 > X-Lines: 13 > > Our society has created a fictional time system of 32 time zones > (24 one-hour offsets and several more half-hour and three-quarter > hour offsets). > > --Tognazzini, Bruce (tog(a)eng.sun.com) "Tog on Interface: > The Myth of Precision", Sun World, volume 6, number 7 > (June, 1993), page 100. > > A grep in /usr/lib/zoneinfo/* on a SunOS 4.1.1 system failed to show up eight > oddball time zones (see attached). Does anyone know of the origin for the > "32" time zones? > > --ado >

1 0

Re: "32 time zones"
by Amos Shapir June 8, 1993

June 8, 1993

Well, you didn't grep hard enough; I just did: grep '[.H][0-9]' /usr/share/lib/zoneinfo/usno1989 And got 11 part-hour zones, 3 of which apply DST which can be also counted as separate timezones; plus Russia's East Siberia zone which is 13 hours ahead of GMT and 14 with DST. In total, we have 24+12+4 or 40 time zones, 36 of which are in use somewhere at any given time. Amos Shapir Net: amos(a)cs.huji.ac.il Paper: The Hebrew Univ. of Jerusalem, Dept. of Comp. Science. Givat-Ram, Jerusalem 91904, Israel Tel: +972 2 585706 GEO: 35 11 46 E / 31 46 21 N

1 0

tzcode93c.tar.Z and tzdata93c.tar.Z
by ado June 6, 1993

June 6, 1993

The latest versions of the time zone stuff are available in the files tzcode93c.tar.Z and tzdata93c.tar.Z in the ~ftp/pub directory on elsie.nci.nih.gov (128.231.16.1). --ado

1 0

Revised draft strftime.c
by ado May 30, 1993

May 30, 1993

An updated draft is available on elsie.nci.nih.gov as ~ftp/pub/draft-strftime.tar.Z, which includes strftime.c and the header files it references. The draft version incorporates the shift to use of sprintf to generate output. This makes the code simpler; it may irk folks who get the standard input/output library dragged in when they call strftime. The handling of "%D" and "%x" have been separated so that they can be changed independently. Right now they're still treated identically in the code; comments have been added giving other possibilities for "%x" handling. The worry is that some piece of code out there is counting on the current "%x" behavior and will break if it is changed. (Yes, counting on "%x" behavior is worng.) As always, any comments are welcome. --ado

1 0

more on ISO date format
by eggert＠spot.twinsun.com May 30, 1993

May 30, 1993

I did some more research on ISO date format, and discovered that the ISO 2014 standard has been superseded by ISO 8601:1988. The date format hasn't changed, however. You can find a summary of ISO 8601:1988 in ftp.uni-erlangen.de:pub/doc/ISO/english/ISO8601.ps.Z.

1 0

Re: proposed changes to strftime.c
by ado May 30, 1993

May 30, 1993

> Use ISO standard date format for %x; this is more appropriate than the > American date format, which confuses non-Americans. Especially for > dates like 01/02/03; the ISO date 2003-01-02 is much clearer for > everybody, and it sorts correctly too. Does "ISO standard date format" hear mean that YYYY-MM-DD is what the ISO version of the C language standard requires, or does it mean something else? --ado

2 1

strftime.c tuneups
by eggert＠twinsun.com May 26, 1993

May 26, 1993

Here are a couple of performance tuneups for strftime.c. 1. Instead of using arrays of pointers to arrays of chars, use two-dimensional arrays of chars, since the sizes are all known. This tends to use less space (since you don't need to store the pointers) and time (since you don't need to indirect through them. 2. Instead of passing around a pointer and pointer to size, incrementing the former and decrementing the latter indirectly, just pass around a pointer and its limit. That way, you can avoid the extra indirection and decrementation. These two changes lop 10% off the code size (sparc, GCC 2.4.0 with -O2). Here's a patch, which assumes my previous patch was applied. *** draft-strftime1.c Tue May 25 11:28:38 1993 --- draft-strftime2.c Tue May 25 21:07:08 1993 *************** *** 32,56 **** #include "private.h" #include "tzfile.h" ! static const char * const afmt[] = { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" }; ! static const char * const Afmt[] = { "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday" }; ! static const char * const bfmt[] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" }; ! static const char * const Bfmt[] = { "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December" }; ! static char *_add P((const char *, size_t *, char *)); ! static char *_conv P((int, const char *, size_t *, char *)); ! static char *_fmt P((const char *, const struct tm *, size_t *, char *)); size_t strftime P((char *, size_t, const char *, const struct tm *)); --- 32,56 ---- #include "private.h" #include "tzfile.h" ! static const char afmt[][4] = { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" }; ! static const char Afmt[][10] = { "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday" }; ! static const char bfmt[][4] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" }; ! static const char Bfmt[][10] = { "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December" }; ! static char *_add P((const char *, char *, const char *)); ! static char *_conv P((int, const char *, char *, const char *)); ! static char *_fmt P((const char *, const struct tm *, char *, const char *)); size_t strftime P((char *, size_t, const char *, const struct tm *)); *************** *** 61,82 **** const char *format; const struct tm *t; { ! size_t gsize; ! gsize = maxsize; ! s = _fmt(format, t, &gsize, s); ! if (gsize <= 0) return 0; ! *s = '\0'; ! return maxsize - gsize; } static char * ! _fmt(format, t, gsizep, pt) const char *format; const struct tm *t; - size_t *gsizep; char *pt; { for (; *format; ++format) { if (*format == '%') { --- 61,81 ---- const char *format; const struct tm *t; { ! char *p; ! p = _fmt(format, t, s, s + maxsize); ! if (p == s + maxsize) return 0; ! *p = '\0'; ! return p - s; } static char * ! _fmt(format, t, pt, ptlim) const char *format; const struct tm *t; char *pt; + const char *ptlim; { for (; *format; ++format) { if (*format == '%') { *************** *** 87,109 **** break; case 'A': pt = _add((t->tm_wday < 0 || t->tm_wday > 6) ? ! "?" : Afmt[t->tm_wday], gsizep, pt); continue; case 'a': pt = _add((t->tm_wday < 0 || t->tm_wday > 6) ? ! "?" : afmt[t->tm_wday], gsizep, pt); continue; case 'B': pt = _add((t->tm_mon < 0 || t->tm_mon > 11) ? ! "?" : Bfmt[t->tm_mon], gsizep, pt); continue; case 'b': case 'h': pt = _add((t->tm_mon < 0 || t->tm_mon > 11) ? ! "?" : bfmt[t->tm_mon], gsizep, pt); continue; case 'c': ! pt = _fmt("%D %X", t, gsizep, pt); continue; case 'C': /* --- 86,108 ---- break; case 'A': pt = _add((t->tm_wday < 0 || t->tm_wday > 6) ? ! "?" : Afmt[t->tm_wday], pt, ptlim); continue; case 'a': pt = _add((t->tm_wday < 0 || t->tm_wday > 6) ? ! "?" : afmt[t->tm_wday], pt, ptlim); continue; case 'B': pt = _add((t->tm_mon < 0 || t->tm_mon > 11) ? ! "?" : Bfmt[t->tm_mon], pt, ptlim); continue; case 'b': case 'h': pt = _add((t->tm_mon < 0 || t->tm_mon > 11) ? ! "?" : bfmt[t->tm_mon], pt, ptlim); continue; case 'c': ! pt = _fmt("%D %X", t, pt, ptlim); continue; case 'C': /* *************** *** 114,120 **** ** (ado, 5/24/93) */ pt = _conv((t->tm_year + TM_YEAR_BASE) / 100, ! "%02d", gsizep, pt); continue; case 'D': case 'x': --- 113,119 ---- ** (ado, 5/24/93) */ pt = _conv((t->tm_year + TM_YEAR_BASE) / 100, ! "%02d", pt, ptlim); continue; case 'D': case 'x': *************** *** 129,138 **** ** numbers (as here) makes Quakers happier. ** This is the ISO standard date format. */ ! pt = _fmt("%Y-%m-%d", t, gsizep, pt); continue; case 'd': ! pt = _conv(t->tm_mday, "%02d", gsizep, pt); continue; case 'E': case 'O': --- 128,137 ---- ** numbers (as here) makes Quakers happier. ** This is the ISO standard date format. */ ! pt = _fmt("%Y-%m-%d", t, pt, ptlim); continue; case 'd': ! pt = _conv(t->tm_mday, "%02d", pt, ptlim); continue; case 'E': case 'O': *************** *** 149,166 **** */ goto label; case 'e': ! pt = _conv(t->tm_mday, "%2d", gsizep, pt); continue; case 'H': ! pt = _conv(t->tm_hour, "%02d", gsizep, pt); continue; case 'I': pt = _conv((t->tm_hour % 12) ? (t->tm_hour % 12) : 12, ! "%02d", gsizep, pt); continue; case 'j': ! pt = _conv(t->tm_yday + 1, "%03d", gsizep, pt); continue; case 'k': /* --- 148,165 ---- */ goto label; case 'e': ! pt = _conv(t->tm_mday, "%2d", pt, ptlim); continue; case 'H': ! pt = _conv(t->tm_hour, "%02d", pt, ptlim); continue; case 'I': pt = _conv((t->tm_hour % 12) ? (t->tm_hour % 12) : 12, ! "%02d", pt, ptlim); continue; case 'j': ! pt = _conv(t->tm_yday + 1, "%03d", pt, ptlim); continue; case 'k': /* *************** *** 173,186 **** ** "%l" have been swapped. ** (ado, 5/24/93) */ ! pt = _conv(t->tm_hour, "%2d", gsizep, pt); continue; #ifdef KITCHEN_SINK case 'K': /* ** After all this time, still unclaimed! */ ! pt = _add("kitchen sink", gsizep, pt); continue; #endif /* defined KITCHEN_SINK */ case 'l': --- 172,185 ---- ** "%l" have been swapped. ** (ado, 5/24/93) */ ! pt = _conv(t->tm_hour, "%2d", pt, ptlim); continue; #ifdef KITCHEN_SINK case 'K': /* ** After all this time, still unclaimed! */ ! pt = _add("kitchen sink", pt, ptlim); continue; #endif /* defined KITCHEN_SINK */ case 'l': *************** *** 195,234 **** */ pt = _conv((t->tm_hour % 12) ? (t->tm_hour % 12) : 12, ! "%2d", gsizep, pt); continue; case 'M': ! pt = _conv(t->tm_min, "%02d", gsizep, pt); continue; case 'm': ! pt = _conv(t->tm_mon + 1, "%02d", gsizep, pt); continue; case 'n': ! pt = _add("\n", gsizep, pt); continue; case 'p': pt = _add(t->tm_hour >= 12 ? "PM" : "AM", ! gsizep, pt); continue; case 'R': ! pt = _fmt("%H:%M", t, gsizep, pt); continue; case 'r': ! pt = _fmt("%I:%M:%S %p", t, gsizep, pt); continue; case 'S': ! pt = _conv(t->tm_sec, "%02d", gsizep, pt); continue; case 'T': case 'X': ! pt = _fmt("%H:%M:%S", t, gsizep, pt); continue; case 't': ! pt = _add("\t", gsizep, pt); continue; case 'U': pt = _conv((t->tm_yday + 7 - t->tm_wday) / 7, ! "%02d", gsizep, pt); continue; case 'u': /* --- 194,233 ---- */ pt = _conv((t->tm_hour % 12) ? (t->tm_hour % 12) : 12, ! "%2d", pt, ptlim); continue; case 'M': ! pt = _conv(t->tm_min, "%02d", pt, ptlim); continue; case 'm': ! pt = _conv(t->tm_mon + 1, "%02d", pt, ptlim); continue; case 'n': ! pt = _add("\n", pt, ptlim); continue; case 'p': pt = _add(t->tm_hour >= 12 ? "PM" : "AM", ! pt, ptlim); continue; case 'R': ! pt = _fmt("%H:%M", t, pt, ptlim); continue; case 'r': ! pt = _fmt("%I:%M:%S %p", t, pt, ptlim); continue; case 'S': ! pt = _conv(t->tm_sec, "%02d", pt, ptlim); continue; case 'T': case 'X': ! pt = _fmt("%H:%M:%S", t, pt, ptlim); continue; case 't': ! pt = _add("\t", pt, ptlim); continue; case 'U': pt = _conv((t->tm_yday + 7 - t->tm_wday) / 7, ! "%02d", pt, ptlim); continue; case 'u': /* *************** *** 238,244 **** ** (ado, 5/24/93) */ pt = _conv((t->tm_wday == 0) ? 7 : t->tm_wday, ! "%d", gsizep, pt); continue; case 'V': /* --- 237,243 ---- ** (ado, 5/24/93) */ pt = _conv((t->tm_wday == 0) ? 7 : t->tm_wday, ! "%d", pt, ptlim); continue; case 'V': /* *************** *** 270,276 **** i = (t->tm_yday + 10 - (t->tm_wday ? (t->tm_wday - 1) : 6)) / 7; pt = _conv((i == 0) ? 53 : i, ! "%02d", gsizep, pt); } continue; case 'v': --- 269,275 ---- i = (t->tm_yday + 10 - (t->tm_wday ? (t->tm_wday - 1) : 6)) / 7; pt = _conv((i == 0) ? 53 : i, ! "%02d", pt, ptlim); } continue; case 'v': *************** *** 279,315 **** ** "date as dd-bbb-YYYY" ** (ado, 5/24/93) */ ! pt = _fmt("%e-%b-%Y", t, gsizep, pt); continue; case 'W': pt = _conv((t->tm_yday + 7 - (t->tm_wday ? (t->tm_wday - 1) : 6)) / 7, ! "%02d", gsizep, pt); continue; case 'w': ! pt = _conv(t->tm_wday, "%d", gsizep, pt); continue; case 'y': pt = _conv((t->tm_year + TM_YEAR_BASE) % 100, ! "%02d", gsizep, pt); continue; case 'Y': pt = _conv(t->tm_year + TM_YEAR_BASE, "%04d", ! gsizep, pt); continue; case 'Z': #ifdef TM_ZONE if (t->TM_ZONE) ! pt = _add(t->TM_ZONE, gsizep, pt); else #endif /* defined TM_ZONE */ if (t->tm_isdst == 0 || t->tm_isdst == 1) { extern char * tzname[2]; pt = _add(tzname[t->tm_isdst], ! gsizep, pt); ! } else pt = _add("?", gsizep, pt); continue; case '%': /* --- 278,314 ---- ** "date as dd-bbb-YYYY" ** (ado, 5/24/93) */ ! pt = _fmt("%e-%b-%Y", t, pt, ptlim); continue; case 'W': pt = _conv((t->tm_yday + 7 - (t->tm_wday ? (t->tm_wday - 1) : 6)) / 7, ! "%02d", pt, ptlim); continue; case 'w': ! pt = _conv(t->tm_wday, "%d", pt, ptlim); continue; case 'y': pt = _conv((t->tm_year + TM_YEAR_BASE) % 100, ! "%02d", pt, ptlim); continue; case 'Y': pt = _conv(t->tm_year + TM_YEAR_BASE, "%04d", ! pt, ptlim); continue; case 'Z': #ifdef TM_ZONE if (t->TM_ZONE) ! pt = _add(t->TM_ZONE, pt, ptlim); else #endif /* defined TM_ZONE */ if (t->tm_isdst == 0 || t->tm_isdst == 1) { extern char * tzname[2]; pt = _add(tzname[t->tm_isdst], ! pt, ptlim); ! } else pt = _add("?", pt, ptlim); continue; case '%': /* *************** *** 321,356 **** break; } } ! if (*gsizep <= 0) return pt; *pt++ = *format; - --*gsizep; } return pt; } static char * ! _conv(n, format, gsizep, pt) int n; const char *format; - size_t *gsizep; char *pt; { char buf[21]; /* Room for - 2**63 ("-9223372036854775808") + null. */ (void) sprintf(buf, format, n); ! return _add(buf, gsizep, pt); } static char * ! _add(str, gsizep, pt) const char *str; - size_t *gsizep; char *pt; { ! while (*gsizep > 0 && (*pt = *str++) != '\0') { ++pt; - --*gsizep; } return pt; } --- 320,353 ---- break; } } ! if (pt == ptlim) return pt; *pt++ = *format; } return pt; } static char * ! _conv(n, format, pt, ptlim) int n; const char *format; char *pt; + const char *ptlim; { char buf[21]; /* Room for - 2**63 ("-9223372036854775808") + null. */ (void) sprintf(buf, format, n); ! return _add(buf, pt, ptlim); } static char * ! _add(str, pt, ptlim) const char *str; char *pt; + const char *ptlim; { ! while (pt < ptlim && (*pt = *str++) != '\0') { ++pt; } return pt; }

1 0

updated strftime.c
by ado May 25, 1993

May 25, 1993

An updated draft strftime.c, with changes from Bradley White (bww+(a)transarc.com) to avoid problems on multiprocessor systems, is available for anonymous ftp from elsie.nci.nih.gov (128.231.16.1) in the "pub" directory, file "draft-strftime.c". As Bradley noted in correspondence, it also: - removes _conv()'s static [non-const] buffer - corrects a problem with _conv() most easily seen with "%k" when tm_hour == 0 - can use the first char of _conv()'s new, non-static buffer - eliminates _conv()'s ASCII dependency - adds a missing _fmt()-parameter in the "%v" case (I've reformatted "strftime.c" just slightly from what bww sent me.) Again, any and all feedback is welcome; correspondence might best be sent to tz(a)elsie.nci.nih.gov. --ado

2 1

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