- tz - lists.iana.org

Australian daylight savings time [forwarded with permission]
by ado April 11, 1994

April 11, 1994

> From connolly(a)zk3.dec.com Fri Apr 8 14:35:03 1994 > Return-Path: <connolly(a)zk3.dec.com> > Received: from decvax.dec.com (decvax.zk3.dec.com) by elsie.nci.nih.gov (4.1/SMI-4.1) > id AA16343; Fri, 8 Apr 94 14:35:01 EDT > Received: from quarry.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92) > id AA00453; Fri, 8 Apr 1994 14:34:58 -0400 > Received: from localhost by quarry.zk3.dec.com; (5.65/1.1.8.2/07Apr94-0144PM) > id AA06464; Fri, 8 Apr 1994 14:34:56 -0400 > Message-Id: <9404081834.AA06464(a)quarry.zk3.dec.com> > To: ado(a)elsie.nci.nih.gov > Cc: connolly(a)quarry.zk3.dec.com > Subject: Australian daylight savings time > Date: Fri, 08 Apr 94 14:34:56 -0400 > From: connolly(a)zk3.dec.com > X-Mts: smtp > Status: RO > > Arthur, > > I am tracking down a problem reported by a customer. He indicates that the > zoneinfo for South Australia is off by one week. > > I have no idea if he is correct or not but I assume he is if he lives there. Is there there a way to check this officially > and if it is wrong I would like to see the change made in the right places. The > file contains the following rule: > > Rule AS 1990 max even Mar Sun>=22 3:00 0 - > > He has suggested the rule be changed to: > > Rule AS 1990 max even Mar Sun>=15 3:00 0 - > > Any help on this would be greatly appreciated. > > John Connolly

1 0

Re: problems with tz-1994e `date'+mktime and Solaris 2.3 strftime
by eggert＠twinsun.com April 8, 1994

April 8, 1994

I think I've figured out the problem with tz-1994e under Solaris 2.3. Guy Harris's intuition was right -- it was the leading-`_' symbols. The problem is that tz-1994e's `date' command calls Sun's strftime, which invokes mktime to set _tzname (not tzname, since a non-Posix Standard C program might have its own external variable called tzname, so the Sun tzname is a weak reference to _tzname). But the tz package defines its own mktime, which sets tzname (which is qnot _tzname). Sun's mktime never gets invoked and therefore Sun's _tzname never gets initialized. I think that this bug will happen in any SVR4 system, regardless of whether -DUSG_COMPAT and -DTM_GMTOFF. The only fix that I can see for tz is the one I already submitted, namely to use tz's strftime instead of the one supplied with the system, as follows: =================================================================== RCS file: Makefile,v retrieving revision 1994.5.1.1 retrieving revision 1994.5.1.2 diff -c -r1994.5.1.1 -r1994.5.1.2 *** Makefile 1994/04/03 02:54:41 1994.5.1.1 --- Makefile 1994/04/03 19:47:59 1994.5.1.2 *************** *** 280,292 **** if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib $@ ; fi ! # We use the system's logwtmp and strftime in preference to ours if available. date: $(DATEOBJS) ! ar r ,lib.a logwtmp.o strftime.o if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib ,lib.a ; fi ! $(CC) $(CFLAGS) date.o localtime.o asctime.o getopt.o \ -lc ,lib.a -o $@ rm -f ,lib.a --- 280,292 ---- if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib $@ ; fi ! # We use the system's getopt and logwtmp in preference to ours if available. date: $(DATEOBJS) ! ar r ,lib.a getopt.o logwtmp.o if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib ,lib.a ; fi ! $(CC) $(CFLAGS) date.o localtime.o asctime.o strftime.o \ -lc ,lib.a -o $@ rm -f ,lib.a

1 0

Re: linking problems with tz-1994e `date' on Solaris 2.3
by Joel.Tornatore＠Eng.Sun.COM April 7, 1994

April 7, 1994

> > 1. The Solaris 2.3 strftime gets confused about the timezone when > > it's linked together with `date'. I don't have the Solaris 2.3 > > source, so I don't know the details, but my guess is that Solaris 2.3 > > strftime assumes that tzset sets some global variables in the Solaris > > 2.3 library, but since we've substituted our own tzset this assumption > > no longer applies. The symptoms are that `date' prints the correct > > time but with either "GMT" or "" substituted for the time zone name. > > As I remember, in SV-derived systems, "tzset()" will set the "timezone", > "daylight", and "tzname" variables; in systems derived from more recent > SV's (SVR3.1 and later, I think), it also sets "altzone". > > SunOS 5.3 is SVR4-derived, so any time zone code installed on it should > arrange to set "timezone", "altzone", "daylight", and "tzname" when > "tzset()" is called. (It may, I think, reset them if there aren't > single values for them that make sense - e.g., if there are different > time zone abbreviations for standard time at different dates, or > different time zone abbreviations for summer time at different dates, I > think "localtime()" may change the setting of "tzname". That, at least, > was the intent.) > > It may be that "strftime()" is expecting "tzname" to be set; if it's not > being set, that may be the source of the problem. The SunOS 5.3 version of tzset() does set these variables: timezone daylight tzname altzone and it does reset them if TZ is not set properly. localtime() calls tzset(), so it will change the tzname[] values. joel

3 4

linking problems with tz-1994e `date' on Solaris 2.3
by eggert＠lotl.twinsun.com April 4, 1994

April 4, 1994

I had two problems linking tz-1994e `date' under Solaris 2.3. 1. The Solaris 2.3 strftime gets confused about the timezone when it's linked together with `date'. I don't have the Solaris 2.3 source, so I don't know the details, but my guess is that Solaris 2.3 strftime assumes that tzset sets some global variables in the Solaris 2.3 library, but since we've substituted our own tzset this assumption no longer applies. The symptoms are that `date' prints the correct time but with either "GMT" or "" substituted for the time zone name. The workaround is to use tz's strftime instead. 2. The system `getopt' and tz `getopt' clash as follows. In Solaris 2.3, `getopt' is broken into two object modules to make its more efficient in a shared library. One, `opt_data.o', merely contains the modifiable data (optind, optarg, opterr, and optopt). (The other, getopt.o, contains the code.) opt_data.o contains definitions for all four symbols, whereas tz's getopt contains two definitions (opterr and optind) and two common symbols (optopt and optarg). This confuses the Solaris 2.3 linker: it brings in opt_data to resolve the common symbols, but then it complains that opterr and optind are multiply defined. Here are the symptoms: gcc -static -Dlint -g -O -Wall -DTZDIR=\"etc/zoneinfo\" date.o localtime.o asctime.o getopt.o \ -lc ,lib.a -o date ld: fatal: symbol `optind' is multiply defined: (file getopt.o and file /usr/lib/libc.a(opt_data.o)); ld: fatal: symbol `opterr' is multiply defined: (file getopt.o and file /usr/lib/libc.a(opt_data.o)); ld: fatal: File processing errors. No output written to date *** Error code 1 One patch might be to modify tz's getopt.c to statically initialize optopt and optarg to 0 (I haven't tested this). Another patch, which I've taken below, is to use the system getopt if it is available. Here is a patch that embodies the above two suggestions. =================================================================== RCS file: Makefile,v retrieving revision 1994.5.1.1 retrieving revision 1994.5.1.2 diff -c -r1994.5.1.1 -r1994.5.1.2 *** Makefile 1994/04/03 02:54:41 1994.5.1.1 --- Makefile 1994/04/03 19:47:59 1994.5.1.2 *************** *** 280,292 **** if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib $@ ; fi ! # We use the system's logwtmp and strftime in preference to ours if available. date: $(DATEOBJS) ! ar r ,lib.a logwtmp.o strftime.o if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib ,lib.a ; fi ! $(CC) $(CFLAGS) date.o localtime.o asctime.o getopt.o \ -lc ,lib.a -o $@ rm -f ,lib.a --- 280,292 ---- if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib $@ ; fi ! # We use the system's getopt and logwtmp in preference to ours if available. date: $(DATEOBJS) ! ar r ,lib.a getopt.o logwtmp.o if [ -x /usr/ucb/ranlib -o -x /usr/bin/ranlib ] ; \ then ranlib ,lib.a ; fi ! $(CC) $(CFLAGS) date.o localtime.o asctime.o strftime.o \ -lc ,lib.a -o $@ rm -f ,lib.a

2 1

mktime bugs around the edges
by eggert＠lotl.twinsun.com April 3, 1994

April 3, 1994

Here are some mktime bugs in tz-1994e. (Bugs that PCTS should have caught :-) mktime fails on the earliest representable time (Fri Dec 13 20:45:52 1901 GMT). mktime does not fail, as it should, with one plus the last representable time (i.e. with Tue Jan 19 03:14:08 2038 GMT). It wraps around and reports Fri Dec 13 20:45:52 1901 GMT instead. When normalizing times, mktime assumes that every minute contains 60 seconds. This is incorrect if leap seconds are in use. mktime does not detect arithmetic overflow when normalizing nonsensically large inputs. Here is a patch. =================================================================== RCS file: localtime.c,v retrieving revision 1994.5.1.1 retrieving revision 1994.5.1.2 diff -c2 -r1994.5.1.1 -r1994.5.1.2 *** localtime.c 1994/04/03 02:54:41 1994.5.1.1 --- localtime.c 1994/04/03 21:25:32 1994.5.1.2 *************** *** 114,118 **** static void localsub P((const time_t * timep, long offset, struct tm * tmp)); ! static void normalize P((int * tensptr, int * unitsptr, int base)); static void settzname P((void)); static time_t time1 P((struct tm * tmp, --- 114,120 ---- static void localsub P((const time_t * timep, long offset, struct tm * tmp)); ! static int increment_overflow P((int * number, int delta)); ! static int normalize_overflow P((int * tensptr, int * unitsptr, ! int base)); static void settzname P((void)); static time_t time1 P((struct tm * tmp, *************** *** 1155,1160 **** */ ! static void ! normalize(tensptr, unitsptr, base) int * const tensptr; int * const unitsptr; --- 1157,1172 ---- */ ! static int ! increment_overflow(number, delta) ! int * number; ! int delta; ! { ! int number0 = *number; ! *number = number0 + delta; ! return (*number < number0) != (delta < 0); ! } ! ! static int ! normalize_overflow(tensptr, unitsptr, base) int * const tensptr; int * const unitsptr; *************** *** 1166,1171 **** (*unitsptr / base) : (-1 - (-1 - *unitsptr) / base); - *tensptr += tensdelta; *unitsptr -= tensdelta * base; } --- 1178,1183 ---- (*unitsptr / base) : (-1 - (-1 - *unitsptr) / base); *unitsptr -= tensdelta * base; + return increment_overflow(tensptr, tensdelta); } *************** *** 1204,1225 **** *okayp = FALSE; yourtm = *tmp; ! if (yourtm.tm_sec >= SECSPERMIN + 2 || yourtm.tm_sec < 0) ! normalize(&yourtm.tm_min, &yourtm.tm_sec, SECSPERMIN); ! normalize(&yourtm.tm_hour, &yourtm.tm_min, MINSPERHOUR); ! normalize(&yourtm.tm_mday, &yourtm.tm_hour, HOURSPERDAY); ! normalize(&yourtm.tm_year, &yourtm.tm_mon, MONSPERYEAR); while (yourtm.tm_mday <= 0) { ! --yourtm.tm_year; ! yourtm.tm_mday += ! year_lengths[isleap(yourtm.tm_year + TM_YEAR_BASE)]; } while (yourtm.tm_mday > DAYSPERLYEAR) { ! yourtm.tm_mday -= ! year_lengths[isleap(yourtm.tm_year + TM_YEAR_BASE)]; ! ++yourtm.tm_year; } for ( ; ; ) { ! i = mon_lengths[isleap(yourtm.tm_year + ! TM_YEAR_BASE)][yourtm.tm_mon]; if (yourtm.tm_mday <= i) break; --- 1216,1236 ---- *okayp = FALSE; yourtm = *tmp; ! if ( normalize_overflow(&yourtm.tm_hour, &yourtm.tm_min, MINSPERHOUR) ! || normalize_overflow(&yourtm.tm_mday, &yourtm.tm_hour, HOURSPERDAY) ! || normalize_overflow(&yourtm.tm_year, &yourtm.tm_mon, MONSPERYEAR) ! || increment_overflow(&yourtm.tm_year, TM_YEAR_BASE)) ! return WRONG; while (yourtm.tm_mday <= 0) { ! if (increment_overflow(&yourtm.tm_year, -1)) ! return WRONG; ! yourtm.tm_mday += year_lengths[isleap(yourtm.tm_year)]; } while (yourtm.tm_mday > DAYSPERLYEAR) { ! yourtm.tm_mday -= year_lengths[isleap(yourtm.tm_year)]; ! if (increment_overflow(&yourtm.tm_year, 1)) ! return WRONG; } for ( ; ; ) { ! i = mon_lengths[isleap(yourtm.tm_year)][yourtm.tm_mon]; if (yourtm.tm_mday <= i) break; *************** *** 1227,1235 **** if (++yourtm.tm_mon >= MONSPERYEAR) { yourtm.tm_mon = 0; ! ++yourtm.tm_year; } } ! saved_seconds = yourtm.tm_sec; ! yourtm.tm_sec = 0; /* ** Calculate the number of magnitude bits in a time_t --- 1238,1264 ---- if (++yourtm.tm_mon >= MONSPERYEAR) { yourtm.tm_mon = 0; ! if (increment_overflow(&yourtm.tm_year, 1)) ! return WRONG; } } ! if (increment_overflow(&yourtm.tm_year, -TM_YEAR_BASE)) ! return WRONG; ! if (yourtm.tm_year < EPOCH_YEAR - TM_YEAR_BASE) { ! /* ! ** We can't set tm_sec to 0, because that might push the ! ** time below the minimum representable time. ! ** Set tm_sec to 59 instead. ! ** This assumes that the minimum representable time is ! ** not in the same minute that a leap second was deleted from, ! ** which is a safer assumption than using 58 would be. ! */ ! if (increment_overflow(&yourtm.tm_sec, 1 - SECSPERMIN)) ! return WRONG; ! saved_seconds = yourtm.tm_sec; ! yourtm.tm_sec = SECSPERMIN - 1; ! } else { ! saved_seconds = yourtm.tm_sec; ! yourtm.tm_sec = 0; ! } /* ** Calculate the number of magnitude bits in a time_t *************** *** 1298,1302 **** } label: ! t += saved_seconds; (*funcp)(&t, offset, tmp); *okayp = TRUE; --- 1327,1334 ---- } label: ! newt = t + saved_seconds; ! if ((newt < t) != (saved_seconds < 0)) ! return WRONG; ! t = newt; (*funcp)(&t, offset, tmp); *okayp = TRUE;

1 0

Re: mktime() failures under PCTS testing
by eggert＠twinsun.com April 1, 1994

April 1, 1994

Mark Brader, who I believe is well connected with the C standardization process, wrote a news article about the mktime problem in which he indicated that he thought that mktime could yield -1 in the spring-forward gap (i.e. that this particular PCTS case is incorrect). I'll enclose a copy of the article at the end of this message. (It responds to another article that I don't have a copy of.) This is probably the best we can do until I get an official response to the C Standard defect report that I filed earlier this week. ----- Newsgroups: comp.std.c From: msb(a)sq.sq.com (Mark Brader) Subject: Re: Can mktime return -1 for times in the spring-forward gap? Message-ID: <1994Mar25.173447.2810(a)sq.sq.com> Summary: Yes, it's undefined behavior Organization: SoftQuad Inc., Toronto, Canada References: <Cn4tnp.DvM(a)twinsun.com> <2mr48c$duk(a)usenet.pa.dec.com> Date: Fri, 25 Mar 94 17:34:47 GMT The original question was about mktime() with the tm_isdst member negative, and times in the "spring-forward gap", i.e. the transition to Daylight Saving Time. > I think the standard contradicts itself. The relevant fields are not > restricted to the usual ranges, yet if the calendar time cannot be > represented then mktime returns -1. I think that your example requires > a return of -1, and an example with tm_hour being 27 is a calendar time > that cannot be represented so it requires a return of -1, even though > mktime has to force the fields into the usual ranges. I think that this is a strained interpretation, and that if a ruling was requested, the response would be that the standard is clear enough as it is. The intent of saying that "the original values ... are not restricted to the ranges indicated above" obviously was to allow alternative specifications for a calendar time, so that 27:00 UTC on October 15, 1982, would signify the same as 03:00 UTC on October 16, 1982; and I don't think there is any other reasonable way to read the actual text. > > The Rationale (section 4.12.2.3) clearly allows mktime to yield -1 in the > > ``fall-backward fold'' [i.e. the opposite transition]... > > The rationale conflicts with the standard, and the standard has priority. > If the tm_isdst field is -1, then a time in the "fall-backward fold" is a > calendar time that can be represented in two ways, so it can be represented, > so the return value cannot be -1 ... The Rationale for 4.12.2.3 does not specify what kind of behavior is involved here, but seems to mean that it is unspecified; perhaps that is what was intended. On reading 4.12.2.3/7.12.2.3 in the actual standard, though, I think the behavior is undefined. What it specifies is only that the broken-down time is converted to a calendar time value. For times in the gap and the fold, no well-defined conversion exists. Therefore, as I see it, the general exclusions in 1.6/3.16 and/or 4.1.6/7.1.7 apply, and the behavior is undefined. (And I think that's an unwise choice; I'd rather that it either be unspecified, or implementation-defined, or that -1 be returned.) > Perhaps now is the calendar time for a few more defect reports. Chuckle. I'd say so. > Every technical corrigendum is met by an equally troublesome new defect > report. But then again... -- Mark Brader, msb(a)sq.com | "You keep using that word. I do not think it means SoftQuad Inc., Toronto | what you think it means." -- The Princess Bride This article is in the public domain.

1 0

Re: 18 sec
by Mills＠udel.edu March 31, 1994

March 31, 1994

Garrett, Wrong. See rfc1589 for an explanation. Dave

1 0

tzcode94e.tar.gz
by ado March 31, 1994

March 31, 1994

The file "tzcode94e.tar.gz" is now available for anonymous ftp from the "~ftp/pub" directory of elsie.nci.nih.gov (128.231.16.1); "tzdata94d.tar.gz" remains the latest data file. The new code incorporates a change for the benefit of PCTS; diffs are attached. --ado SCCS/s.Makefile: 7.21 vs. 7.23 *** 7.21/Makefile Wed Mar 30 23:32:14 1994 --- 7.23/Makefile Wed Mar 30 23:32:15 1994 *************** *** 1,4 **** ! # @(#)Makefile 7.21 # Change the line below for your time zone (after finding the zone you want in # the time zone files, or adding it to a time zone file). --- 1,4 ---- ! # @(#)Makefile 7.23 # Change the line below for your time zone (after finding the zone you want in # the time zone files, or adding it to a time zone file). *************** *** 168,173 **** --- 168,179 ---- # -DCMUCS # to the end of the "CFLAGS=" line # This function is not described in X3J11's work. + # + # NIST-PCTS:151-2, Version 1.4, (1993-12-03) is a test suite put + # out by the National Institute of Standards and Technology + # which claims to test C and Posix conformance. If you want to pass PCTS, add + # -DPCTS + # to the end of the "CFLAGS=" line. CFLAGS= SCCS/s.localtime.c: 7.17 vs. 7.18 *** 7.17/localtime.c Wed Mar 30 23:32:17 1994 --- 7.18/localtime.c Wed Mar 30 23:32:18 1994 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.17"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 7.18"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 1308,1315 **** --- 1308,1326 ---- if (tmp->tm_isdst > 1) tmp->tm_isdst = 1; t = time2(tmp, funcp, offset, &okay); + #ifdef PCTS + /* + ** PCTS code courtesy Grant Sullivan (grant(a)osf.org) + */ + if (okay) + return t; + if (tmp->tm_isdst < 0) + tmp->tm_isdst = 0; /* reset to std and try again */ + #endif /* defined PCTS */ + #ifndef PCTS if (okay || tmp->tm_isdst < 0) return t; + #endif /* !defined PCTS */ /* ** We're supposed to assume that somebody took a time of one type ** and did some math on it that yielded a "struct tm" that's bad.

1 0

18 sec
by Garrett Wollman March 29, 1994

March 29, 1994

<<On Tue, 29 Mar 1994 10:12:19 +0200 (MESZ), Hinrich Eilts <eilts(a)late.e-technik.uni-erlangen.de> said: > I synchronized FreeBSD-1.1-BETA to a stratum-1 timeserver by ntpdate > and xntpd and compared localtime by "date" with it and two other > machines, which are synchronized by xntpd too. FreeBSD has a > difference of -18 secounds to all other machines (a NeXT-Station > with NeXTStep, a Sun with SunOS 4.x and a HP9000-750 with > HPUX). What you are seeing is the interaction of several different `features' of NTP and FreeBSD. I'll try to explain, and again hope that somebody out there can provide a complete solution. Here are the problems... 1) The timezone database does not reflect the fact that the first time step, in going from GMT (pre-1972) to UTC (1972 to present) was actually 10 seconds, and not just one like all subsequent leap seconds. 2) The timezone database DOES include all subsequent time steps. 3) The NTP code ``handles'' leap seconds by turning the clock back when they happen. By contrast, the timezone code assumes that time_t's are increasing (which they ought to be; I hold that xntpd's behavior is simply wrong). To wit: NTP code wants: Real Time UNIX Time --------------- --------- --------- 30 June 1994, 23:59:59 t s 30 June 1994, 23:59:59 t+1 s 01 July 1994, 00:00:00 t+2 s+1 Timezone code wants: Real Time UNIX Time -------------------- --------- --------- 30 June 1994, 23:59:59 t s 30 June 1994, 23:59:60 t+1 s+1 01 July 1994, 00:00:00 t+2 s+2 A temporary (ugly hack) solution is to use `posix/your/time/zone' rather than `right/your/time/zone' (which is the same as `your/time/zone') for /etc/localtime. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman(a)lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. formerly known as | It is a bond more powerful than absence. We like people wollman(a)emba.uvm.edu | who like Shashish. - Claude McKenzie + Florent Vollant

2 2

Re: 18 sec
by Bradley White March 29, 1994

March 29, 1994

Garrett Wollman <wollman(a)adrastea.lcs.mit.edu> writes: > What you are seeing is the interaction of several different `features' > of NTP and FreeBSD. I'll try to explain, and again hope that somebody > out there can provide a complete solution. Here is an encore of my reply of February 7th. --- Begin forwarded message Date: Mon, 07 Feb 1994 18:05:34 -0500 (EST) From: Bradley White <bww+(a)transarc.com> Subject: Re: leap seconds To: Garrett Wollman <wollman(a)emba.uvm.edu> Cc: Paul Eggert <eggert(a)twinsun.com>, Zone Watchers <tz(a)elsie.nci.nih.gov>, freebsd-tz(a)freefall.cdrom.com Message-Id: <09490.760662334(a)capitol.transarc.com> In-Reply-To: Your message of Mon, 7 Feb 94 17:23:21 -0500 <9402072223.AA23255(a)bajoran.emba.uvm.edu> Any system that runs with ``REDO=right_*'', and which therefore wants to continue to tick normally over leap seconds, needs to do a little bit of work to generate NTP-style timestamps. That is, NTP-style timestamps are discontinuous over leaps, while ``REDO=right_*'' time_t's are continuous. Recent incantations of the `tz' package provide the time2posix() function to help in mapping between these two formats. For example, in the (old, version-1) NTP code, you need to change ... stampp->int_part = htonl(tvp->tv_sec + JAN_1970); to stampp->int_part = htonl(time2posix(tvp->tv_sec) + JAN_1970); I haven't looked at the (new, version-3) XNTP code, but I imagine the change needed there is just as trivial. After that, you will chime NTP harmoniously with the rest of the world, *and*, you will sail smoothly through leap events without the jitter or confusion suffered by your NTP peers. Bradley

1 0