Previous part

From: Chris Raymond <raymond@spof01.gsfc.nasa.gov> [-/+]
Date: Sat, 9 Aug 1997 16:14:44 -0400 (EDT)
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: tickadj gives error on Solaris 2.5.1
[-/+]
X-Keywords: nsec_per_tick
[-/+]

Hi Casper,

Okay, thanks for the correction.  The net effect for this architecture
seems to be the satisfactory same, though.

Chris Raymond

On 9 Aug 1997, Casper H.S. Dik - Network Security Engineer wrote:

> Chris Raymond <raymond@spof01.gsfc.nasa.gov> writes:
>
> >KERNEL nsec_per_tick = 10001000 nsec
> >KERNEL tick = 10001 usec (from nsec_per_tick kernel variable)
<SNIP>
>
> Well, that's not "tick" but "nsec_per_tick" that you've changed (didn't
> know that tickadj had progress that far), but when I said:
>
> >> no alternative exists fo [sic] Ultras.
>
>
> I was correct.  Ultras dp their clocks different and don't
> honor any kernel variable.
>
> (The clock ticks are derived from the %tick and %tick_cmpr register;
> and are so based directly on the systems clock frequency)
>
> Casper
> --
> Expressed in this posting are my opinions.  They are in no way related
> to opinions held by my employer, Sun Microsystems.
> Statements on Sun products included here are not gospel and may
> be fiction rather than truth.
>
>


From: "L. F. Sheldon, Jr." <lsheldon@creighton.edu> [-/+]
Date: Wed, 6 Aug 1997 23:34:20 -0500
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Validating synchronization to 10ms
[-/+]
X-Keywords: configuration
[-/+] documentation [-/+] poll [-/+] release [-/+] stability [-/+]

First and foremost we need to understand that I am not even close to
being an Authority on timekeeping, but I do have some ideas about this
situation.

On Wed, 6 Aug 1997, Brett Kettering wrote:

> In our final system we will have a closed network of many nodes.
> Current plans call for 13 UltraSPARC stations, 4 Enterprise 3000
> workstations, and 8 SPARC CPUs in VME chassises running whatever is the
> latest release of Solaris when we field.  There will also be
> approximately 260 VME chassises with the latest version of VxWorks when
> we field.
>
> We have 1 network-based GPS time unit (with NTP server onboard in ROM)
> on the network with its own IP address.  The goal is to ensure that all
> the nodes think it is the same time to within 10ms so that when logging
> is done by our widely distributed control system that an event can be
> tracked across computers with logs that have monotonically increasing
> time stamps.
>
> The current plan is for all these Solaris and VxWorks computers to use
> the GPS unit as the source of time in our system.  Will this overload
> the GPS unit?

I think it unlikely that it will be overloaded--but that is way off the
edge of my expertise, but I would think that if time is mission-critical,
you would want to have at least two high-quality time sources, so you
can break one, lose one, or have one isolated on the network without
reducing your source count to zero.

If at all possible, I'd include on the time-keeping network at least one
source from a distant point to provide a sanity check on your source(s).

It is not clear to me from your description what your intentions are,
but I would want as many machines running xntpd as you can to keep
things smooth, and to keep the network from wandering off in all directions
if you do lose your source.

> I currently have two Solaris workstations synchronizing their time from
> the GPS unit.  How do I validate that they have their system time set to
> within 10ms of each other?  To this point I have just run the X/Motif
> "clock" application which shows the seconds ticking way together.
>
> I have read and re-read the configuration documentation and I still
> don't understand if there are parameters that I can set in the daemon
> (xntpd) to make it poll the GPS unit more or less frequently depending
> on how close I want the daemon to set the workstation's time to that of
> the GPS unit.  Any pointers to a clear explanation of this?

I don't think you can (or want to) adjust this--the daemons (if I under-
stand this stuff at all) will adjust their polling interval to the smallest
rate that they can and maintain stability.

> How does the frequency at which a daemon polls a time source guarantee a
> synchronization accuracy?

I think what "gaurantees" accuracy is allowing several daemons to
communicate with and cross-check each other--my belief is that this is
what the protocol is all about.
--
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
.                                                                       .
- L. F. (Larry) Sheldon, Jr.                                            -
. Unix Systems Administration                                           .
- Creighton University Computer Center-Old Gym                          -
. 2500 California Plaza                                                 .
- Omaha, Nebraska, U.S.A.  68178       We are all faced with            -
. lsheldon@creighton.edu                  great opportunities           .
- 402 280-2254 (work)                  brilliantly disguised as         -
. 402 681-4726 (cellular)                 impossible situations.        .
- 402 332-4622 (residence)                                              -
.                                           Bits and Pieces             .
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-


From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 8 Aug 1997 16:17:44 -0400
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: What sort of synchronisation is "normal"?
[-/+]

ashtray@replicant.apana.org.au (John Newnham) writes:

>For reference, the xntpd which I run (and wish to improve)
>is on a 486 running linux, on a bursty and relatively
>low-bandwidth network, in a room of varying temperature.
>I am a competent unix admin, but I do not know the details
>of NTP.  The daemon steps its clock at least twice a week,
>sometimes twice in one day (and I have tuned tickadj as
>finely as possible in order to achieve this).  I have some
>ideas on how to improve things, but I was wondering what
>sort of result is considered "good", and what is "achieveable".

I'd guess that the main culprit is the bursty and relatively
low-bandwidth network.  Not the room with varying temperature
or the tuning (or lack thereof) of tickadj.

If you can't improve the bandwidth of the network, there isn't much
you can do to avoid occasionally having your clock get stepped.

That said, there used to be a parameter in the code called something
like "SLEW_ALWAYS" that prevented stepping the clock by replacing it
with calls to adjtime that were somewhat more violent than the usual
ones used by xntpd.  This at least prevented the clock from getting
set backwards by one or more seconds when things went bad.  I'm not
sure if it's still there.  You could grep the source for "SLEW" and
see what you find.

Rick


From: "Ishikawa,Chiaki,remove No Spam from the address"<ishikawa@personal-media.co.No.jp.Spam>
Date: 08 Aug 1997 17:14:03 +0900
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Problem on xntp 3-5-90-export SunOS 4.1.4/Sparc 20
X-Keywords: auth
[-/+] authentication [-/+]

Hello,

My own follow-up:

It seems that the authentication option default setting has changed
between the releases.

A kind soul suggested that I may try putting "disable auth" on the
servers and see what happens because of these differences.
Voila, the client now is receiving time information from the gateway.

Also, I was advised to pick up the 3.-5.90.3-export, and so am running
it in the local LAN now.

Thank you!
--
    Ishikawa, Chiaki        ishikawa@personal-media.co.jp.NoSpam  or
(family name, given name) Chiaki.Ishikawa@personal-media.co.jp.NoSpam
    Personal Media Corp.      ** Remove .NoSpam at the end before use **
  Shinagawa, Tokyo, Japan 142


From: Casper.Dik@Holland.Sun.COM (Casper H.S. Dik - Network Security Engineer) [-/+]
Date: 9 Aug 1997 13:30:24 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: tickadj gives error on Solaris 2.5.1
[-/+]
X-Keywords: dosynctodr
[-/+] nsec_per_tick [-/+]

Chris Raymond <raymond@spof01.gsfc.nasa.gov> writes:

>KERNEL nsec_per_tick = 10001000 nsec
>KERNEL tick = 10001 usec (from nsec_per_tick kernel variable)
>PRESET tick = 10000 usec
>dosynctodr is off
>KERNEL hz = 100
>calculated hz = 100.00 Hz

>So it seems your blanket statement about Solaris 2.5.1 was not
>correct.

Well, that's not "tick" but "nsec_per_tick" that you've changed (didn't
know that tickadj had progress that far), but when I said:

>> no alternative exists fo [sic] Ultras.

I was correct.  Ultras dp their clocks different and don't
honor any kernel variable.

(The clock ticks are derived from the %tick and %tick_cmpr register;
and are so based directly on the systems clock frequency)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.


From: robk@oldtimer.win-uk.net (Robin Kimberley) [-/+]
Date: Wed, 13 Aug 1997 15:42:09 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Radio Clock & xntpd
[-/+]
X-Keywords: compatible
[-/+] Datum [-/+]

In article <>, Kevin Cousins (cousinsk@sg.adisys.com.au) writes:
>
>
>James> Can anyone reccomend a vendor for an xntpd-compatible radio clock?
>
>David> DATUM       - use Datum Programmable Time System
>...

Kevin,

Why not take a look at Datum's TS2100 Network Time Server. GPS
front end, and NTP out on either AUI or 10baseT ethernet. All the
hard work has been done inside the "box". Just set up the IP
address and away you go!

Info available on Datum's Web site www.datum.com

We sell these units in the UK (very popular), but I believe the
Datum Rep in Australia is Scientific Devices Ltd (contact Graham
Sharpe?).

Good luck.

Rob Kimberley

Product Manager, Time and Frequency
Sematron UK Limited

Tel: ++44 1256 812 222
Fax: ++44 1256 812 666
Web: http://www.sematron.com
Mail: rkimberley@sematron.com

Home:-

Tel : ++44 1926 613 162
Fax : ++44 1926 613 775
Mail: robk@oldtimer.win-uk.net


From: "Marc Brett" <Marc.Brett@waii.com> [-/+]
Date: 18 Aug 1997 11:58:45 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions?
[-/+]
X-Keywords: ACTS
[-/+] CHU [-/+] DCF77 [-/+] LORAN TAI [-/+]

Robin O'Leary <robin@acm.nospam.org> wrote:
> In article <5qddnt$m96$1@pheidippides.axion.bt.co.uk>, John Sager
> <jcs@zoo.bt.co.uk> wrote:
> > I now think that NTP should support TAI in some form. My previous view
> > was that most NTP users needed UTC, so this should be the main offering,
> > whereas TAI users, being much in the minority, should bear the pain of doing
> > the conversion. However I now think that TAI will become increasingly
> > sought after on the net.

> Hooray!  I hope John Sager's article will inaugurate the long-overdue
> Campaign for Real Time!

Sorry, but I must disagree with this "UTC considered harmful" bandwagon.

UTC is legal civil time in most of the world, and everything in people's
day-to-day lives synchronizes with it, not TAI.  Computers are tools
which interface with peoples lives, and should, at least externally,
keep the same time as they do: UTC.

Translating from an internal representation of TAI to an external
representation of UTC adds an additional layer of complexity to the
system, and one more thing to go wrong.  Who will maintain the TAI-UTC
offset?  If it has to be done manually, then I guarantee it'll be done
wrong on some if not most systems.  If it's centrally-distributed, who
will do it?  As far as I know, only GPS is capable of distributing TAI
time (which by accident of design makes the TAI-GPS offset a constant).
WWV/WWVB/WWVL/WWVH (USA) can't do it.  ACTS (USA) can't do it.  DCF77
(Germany) and TDF (France) can't do it.  CHU (Canada) can't do it.  MSF
(UK) can't do it.  GLONASS (Russia) can't do it.  Not sure about LORAN
or OMEGA or GOES, but I doubt they can either.  In these instances, the
offset will have to be sent "out-of-band", and no such broadcasting
mechanism exists today.

If you require that NTP carry the TAI-UTC offset, you have to get the
raw information from somewhere.  You must either trust *only* GPS
receivers, or else trust the the thousands of human operators of the
radio receivers listed above to correctly program TAI-UTC offset every
time there is a leap-second event.  Neither is a good option.  Relying
solely on GPS introduces the possibility of a single point of failure
if the GPS system breaks down.  Relying on thousands of unknown
operators, or even your own system administrator, for such an
infrequent and esoteric maintenance task is also unwise.

One of the nice things about NTP is its ability to draw on many
independent time sources.  If you eliminate those time sources which
cannot distribute trustworthy TAI-UTC offsets, then at a stroke you
have eliminated most of of the robustness of the system.

For most users in most situations the leap second is a non-issue.  It
breaks some things, but in most cases the applications and their users
are oblivious to it.  Very few applications actually need the exact
number of seconds between events separated by years.  Coarser time
measurements will usually suffice, and indeed are probably more
apropriate.

There will always exist people who need TAI, but they already have
software to cater to their needs.  Their more exacting demands should
not burden the majority of users who only need and want UTC.

--
Marc Brett  +44 181 560 3160            Western Atlas
Marc.Brett@waii.com                     455 London Road, Isleworth
FAX: +44 181 847 5711                   Middlesex TW7 5AB    England


From: hughett@galton.psycha.upenn.edu (Paul Hughett)
Date: 18 Aug 1997 14:53:32 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions?
[-/+]
X-Keywords: daylight
[-/+] TAI [-/+] timezone [-/+]

Marc Brett (Marc.Brett@waii.com) wrote:
: Robin O'Leary <robin@acm.nospam.org> wrote:
: > In article <5qddnt$m96$1@pheidippides.axion.bt.co.uk>, John Sager
: > <jcs@zoo.bt.co.uk> wrote:
: > > I now think that NTP should support TAI in some form. My previous view
: > > was that most NTP users needed UTC, so this should be the main offering,
: > > whereas TAI users, being much in the minority, should bear the pain of
: > > doing the conversion. However I now think that TAI will become
: > > increasingly sought after on the net.

: > Hooray!  I hope John Sager's article will inaugurate the long-overdue
: > Campaign for Real Time!

: Sorry, but I must disagree with this "UTC considered harmful" bandwagon.

: UTC is legal civil time in most of the world, and everything in people's
: day-to-day lives synchronizes with it, not TAI.  Computers are tools
: which interface with peoples lives, and should, at least externally,
: keep the same time as they do: UTC.

: Translating from an internal representation of TAI to an external
: representation of UTC adds an additional layer of complexity to the
: system, and one more thing to go wrong.  Who will maintain the TAI-UTC
: offset?  If it has to be done manually, then I guarantee it'll be done
: wrong on some if not most systems.  If it's centrally-distributed, who
: will do it?

  [Several paragraphs of details omitted.]

: For most users in most situations the leap second is a non-issue.  It
: breaks some things, but in most cases the applications and their users
: are oblivious to it.  Very few applications actually need the exact
: number of seconds between events separated by years.  Coarser time
: measurements will usually suffice, and indeed are probably more
: apropriate.

: There will always exist people who need TAI, but they already have
: software to cater to their needs.  Their more exacting demands should
: not burden the majority of users who only need and want UTC.

Actually, as far as I know, both Unix and NTP use TAI internally and
convert to UTC only for external output to the users.  The time in
Unix systems is kept as the number of seconds since the beginning of
1970; the exact definition of the second is not specified but is
presumably the atomic second.  Thus, the Unix time variable is TAI
minus an offset equal to TAI at the beginning of the epoch.
Similarly, the time values passed around by NTP are also just the
number of second since the epoch, or TAI.

When you ask for the date in Unix, the system converts to YYYYMMDD
HHMMSS, including the necessary corrections for time zone, leap years,
daylight savings time, and leap seconds.  Except for leap years, which
are hardwired into the code, this information is kept in a file
/etc/localtime (the location varies with different Unix systems);
information for other time zones is kept in /usr/lib/zoneinfo (again,
this varies).  There is a program called zic which creates these
timezone files from a human-readable format.

Now, if you want your machine to express time in TAI externally as well
as internally, all you have to do is to create a TAI time zone which
omits all the leap second corrections but otherwise matches GMT or UTC.
The result cannot, strictly speaking, be called TAI since it is expressed
as YYMMDD HHMMSS rather than number of seconds, but that fine point
probably does not matter within a group who accepts that deviation.

Conversely, if you have not updated your zoneinfo files (or at least
localtime) since the last leap second was announced, your reported UTC
will be off by some number of leap seconds.  Most people won't care;
the few that do care are most likely aware of this and have already
updated the files.

Marc is absolutely correct in saying that keeping TAI internally and
displaying UTC externally is complex and (if you're careless) error
prone; nevertheless, that is how it is actually done in Unix and NTP.

============================================================
Paul Hughett, Ph.D.             Research Associate and
Neuropsychiatry Section         Computer Systems Manager
10th floor Gates Building
Hospital of the University      (215) 662-2826 (voice)
    of Pennsylvania             (215) 662-7903 (fax)
3400 Spruce Street
Philadelphia PA 19104           hughett@bbl.psycha.upenn.edu

        A rose by any other name confuses the issue.
                                  -Patrick E. Raume
============================================================


From: zlsiial@cfs2.mcc.ac.uk (Dr A O V Le Blanc)
Date: 16 Aug 1997 17:04:21 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: What sort of synchronisation is "normal"?
[-/+]
X-Keywords: FAQ
[-/+] Linux [-/+]

ashtray@replicant.apana.org.au (John Newnham) writes:

>Some questions.  In the proto-FAQ for this group is the following text:
...
>     Clock
>     synchronization  at  the  10-millisecond level over long distance
>     (2000 km) WANs, and at the  1-milllisecond  level  for  LANs,  is
>     routinely achieved.

>What sort of accuracy do most people on this newsgroup get?

On our HPs and Suns we usually get remote accuracy of 1 to 10 milliseconds
over long distances, and of about half a millisecond on the local net.

>For reference, the xntpd which I run (and wish to improve)
>is on a 486 running linux, on a bursty and relatively
>low-bandwidth network, in a room of varying temperature.

Current versions of Linux (at least the stable versions 2.0.29 and
2.0.30) don't seem to be easy to tune well.  We very often see the
ntp.drift file reach its maximum value, even after weeks of careful
tinkering with the tick values.  This is one reason why I suggested
earlier that ntp be at least configurable to manage its own tick
and tickadj as well as drift values.

>What factors affect it most -
>       computing hardware?  (VAXen vs. PC)
>       operating system?    (SunOS vs. anything...)
>       network connection?  (latency?  bandwidth?)
>       physical environment?
>       tuning by the administrator?

All of these affect the accuracy of the software, but I've seen
some heavily loaded, cheap old Suns and HPs with more or less everything
against them still keep very accurate time with xntp.

    -- Owen
    LeBlanc@mcc.ac.uk


From: jkb@mrc-lmb.cam.ac.uk (James Bonfield)
Date: 12 Aug 1997 10:10:04 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp,comp.sys.sgi.admin
Subject: Re: xntpd 3-5.90.3 and IRIX 6.3 (R10000).
X-Keywords: SGI
[-/+]

In article <5sfnat$7q2@sifon.cc.mcgill.ca> malin@nil.mni.mcgill.ca writes:
>Until I stumbled on one host, an SGI O2 R10000, running
>IRIX 6.3, a 64 bit kernel. At first this guy was chiming
>alright, then after a reboot, refused to go along...
>started drifting up to 200 secs/day off the servers...

We had an identical situation with an O2 & Irix 6.3, except that we
had around 300 secs/day drift. The solution (thanks to Jon Peatfield
for helping me here) was to use the timetrim program. This comes with
newer xntp distributions, in the utils directory. It uses an SGI
specific system call to adjust a kernel time skewing paramater. The
kernel limits this skew to 0.3%, which in my case wasn't
enough. However as long as you're close enough (which we apparently
were) xntp can take over from there. Read the top of the timetrim.c
file for some brief docs.

However I'd like to know how come these systems have such TERRIBLE
time keeping. Our's was so bad that it wouldn't even be within a day
if you left it alone for a year or so.

        James
--
James Bonfield (jkb@mrc-lmb.cam.ac.uk)   Tel: 01223 402499   Fax: 01223 213556
Medical Research Council - Laboratory of Molecular Biology,
Hills Road, Cambridge, CB2 2QH, England.
Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/


From: Casey Crellin <casey@ccii.REMOVE_THIS.co.za>
Date: Fri, 15 Aug 1997 08:56:33 +0200
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp on VXWorks MC68020 system?

Mike Mohar wrote:

> After a quick review of the docs, it didn't look like
> ntp source has been targeted for a 68020 system? Has
> anyone cross compiled it to this arch.?

    It should soon compile for all vxWorks targets - at least those
using the Tornado environment,  look out for xntp3-5.90.3a.tar.gz or
later these have the patches for vxWorks cross-compile.

    Providing the only difference is the endianess, it should compile
without problem after following the vxworks.html file.

Casey
--
Casey Crellin

CCII Systems (Pty) Ltd                            http://www.ccii.co.za
------------------------------------------------------------------------


From: robk@oldtimer.win-uk.net (Robin Kimberley) [-/+]
Date: Thu, 14 Aug 1997 17:31:09 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SNMP and NTP
[-/+]
X-Keywords: Datum
[-/+] SNTP [-/+]

In article <33F2A6BB.3F7E@abm.com.au>, Carl Brewer (carl@abm.com.au) writes:
>Casey Crellin wrote:
>>
>> Are there any plans for an MIB for ntp?
>>
>> Has anyone ever implemented one?

Datum's TS2100 Network Time Server provides NTP and has SNTP with
MIB as standard. Try Datum's web site www.datum.com and go to the
Bancomm-Timing division.

Rgds

Rob Kimberley


From: Paul Skoog <pskoog@truetime.com>
Date: Fri, 15 Aug 1997 07:54:12 -0700
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SNMP and NTP
[-/+]
X-Keywords: authentication
[-/+] SNTP [-/+] TrueTime [-/+]

Casey Crellin wrote:
>
> Are there any plans for an MIB for ntp?
>
> Has anyone ever implemented one?
>

TrueTime offers the NTS-100 Network Time Server which provides SNTP with
a MIB and MD5 authentication standard as well. They have a new web site
under construction at www.truetime.com with all the current
information(first link takes you to the new site).

--Paul Skoog


From: Carl Brewer <carl@abm.com.au> [-/+]
Date: Thu, 14 Aug 1997 16:33:31 +1000
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SNMP and NTP
[-/+]
X-Keywords: monitor
[-/+]

Casey Crellin wrote:
>
> Are there any plans for an MIB for ntp?
>
> Has anyone ever implemented one?
>
> My initial thought to this was why not use ntpq/xntpdc, but if the would
> be querier does not have these
> it  seems  valid to supply this info to SNMP.
>
> Anyone got 2c worth on this?

I was just thinking of exactly the same thing today.

It would be great to be able to configure SNM (for example) to
monitor if your NTP stuff was sync'ing, and generate an alert if
it died, or switched over to its local hardware clock etc.

I guess the MIB would take some thought, but it'd be pretty
seriously useful.


From: robk@oldtimer.win-uk.net (Robin Kimberley) [-/+]
Date: Fri, 15 Aug 1997 21:22:21 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: SNMP and NTP
[-/+]
X-Keywords: authentication
[-/+] Datum [-/+] SNTP [-/+] TrueTime [-/+]

In article <33F46D94.1217@truetime.com>, Paul Skoog (pskoog@truetime.com) writes:
>Casey Crellin wrote:
>>
>> Are there any plans for an MIB for ntp?
>>
>> Has anyone ever implemented one?
>>
>
>
>TrueTime offers the NTS-100 Network Time Server which provides SNTP with
>a MIB and MD5 authentication standard as well. They have a new web site
>under construction at www.truetime.com with all the current
>information(first link takes you to the new site).
>
>--Paul Skoog

Hi Ya Paul,

Please give my very kind regards to all my old friends at Truetime,
Rick Dielman, Mike Tope, Greg Kret - but I still reckon the Datum
TS2100 is a far far better box (and yes it also has MD5).

Cheers

Rob Kimberley


From: robin@acm.nospam.org (Robin O'Leary) [-/+]
Date: 18 Aug 1997 21:21:20 +0100
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions?
[-/+]
X-Keywords: daylight
[-/+] Linux [-/+] specification [-/+] TAI [-/+] timezone [-/+]

In article <5t9nlc$f6v$1@netnews.upenn.edu>,
Paul Hughett <hughett@galton.psycha.upenn.edu> wrote:
>Actually, as far as I know, both Unix and NTP use TAI internally and
>convert to UTC only for external output to the users.  The time in
>Unix systems is kept as the number of seconds since the beginning of
>1970; the exact definition of the second is not specified but is
>presumably the atomic second.  Thus, the Unix time variable is TAI
>minus an offset equal to TAI at the beginning of the epoch.
>Similarly, the time values passed around by NTP are also just the
>number of second since the epoch, or TAI.

Good idea though it is, unfortunately, this does not seem to be
current practice.  I wish it were.  A literal reading of the POSIX
specification for gettimeofday() does indeed suggest that this is
required for conformance, but certainly Linux, which is quite
aggressively POSIX-compliant in most respects, works in UTC.
This is something I am working on:-)

>When you ask for the date in Unix, the system converts to YYYYMMDD
>HHMMSS, including the necessary corrections for time zone, leap years,
>daylight savings time, and leap seconds.  Except for leap years, which
>are hardwired into the code, this information is kept in a file
>/etc/localtime (the location varies with different Unix systems);
>information for other time zones is kept in /usr/lib/zoneinfo (again,
>this varies).  There is a program called zic which creates these
>timezone files from a human-readable format.

I would like to know what Unix system you are on.  The BSD C library
knows a bit about leap seconds, but it still appears to expect
time-of-day-seconds and timestamps on files to be in UTC.  Try this rather
crude test on your system to check:

#include <stdio.h>
#include <time.h>
#include <sys/time.h>

int main(int argc, char *argv[])
{
        struct timeval secs_and_usecs_since_1970;
        time_t secs_since_1970;
        struct tm *now;
        gettimeofday(&secs_and_usecs_since_1970, NULL);
        secs_since_1970 = secs_and_usecs_since_1970.tv_sec;
        now=localtime(&secs_since_1970);
        printf("gettimeofday returns %s\n",
                (now->tm_sec == (secs_since_1970 % 60))?"UTC":"TAI(?)");
}

It says UTC on Linux, and a look at the kernel source confirms that
(if told to do so by some external agent like NTP) the kernel warps its
internal second-keeping clock on leap-seconds.

> [snip]

>Marc is absolutely correct in saying that keeping TAI internally and
>displaying UTC externally is complex and (if you're careless) error
>prone; nevertheless, that is how it is actually done in Unix and NTP.

Again, I wish it weren't, but NTP is definitely UTC-only.  See RFC1305
which I cited earlier in this thread for confirmation and (IMHO weak)
justification for this decision.  It is because NTP uses UTC not TAI
that we are having this discussion in comp.protocols.time.ntp!

Robin O'Leary.
--
<robin@nospam.acm.org>  +44 973 310035  P.O. Box 20, Swansea SA2 8YB, U.K.


From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 21 Aug 1997 13:25:28 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions?
[-/+]
X-Keywords: GNU
[-/+] implementation [-/+] MVS [-/+] TAI [-/+] update [-/+]

In article <5tbs1v$kgg@swan.ml.org>,
Robin O'Leary <robin@acm.nospam.org> wrote:
>In article <33F8F6C3.3C7F@erols.com>, The Browns  <suneedle@erols.com> wrote:
>
>>Ultimately, we will need every part of the implementation to accomodate
>>both TAI and UTC and that won't come quickly.
>
>I believe it can come quickly once NTP does its bit in distributing TAI
>and TAI-UTC.  The GNU libc code already has all the necessary leap-second
>handling stuff in ready, and with those two layers fixed, applications
>should be completely unaware of the change.

Unfortunately, this statement is the converse of the truth.

Having both UTC and TAI at every layer would cause complete chaos, because
one application would write a timestamp using one and another would check
it using the other.  We already have this with local times.  The ONLY sane
way is to use TAI as the base clock, convert to UTC higher up and then
convert to local time in some applications.

The important point that most conversions of time_t objects are not
done using well-defined and standard interfaces.  They are both used as
unique, increasing timestamps AND as the Unix/POSIX-mangled time since a
virtual epoch.  And the second form is very often converted to and from
other formats directly (i.e. not via the C library).

If you think that this is unreasonable, consider the problem of converting
MVS TOD timestamps to Unix time_t - the former are long seconds (1.04576
seconds) since a different epoch!  And then start considering what can
be done with timestamps embedded in old files (e.g. file update times);
it is CRITICAL to know whether they are TAI or UTC.

Given the fact that POSIX has canonised the lunatic behaviour of broken
C libraries, and the misbegotten half-UTC is used so much in external and
data protocols, there is virtually no chance of changing to TAI.  This is
a pity, but such is life :-(

Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679


From: The Browns <suneedle@erols.com> [-/+]
Date: Mon, 18 Aug 1997 21:28:35 -0400
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions?
[-/+]
X-Keywords: implementation
[-/+] TAI [-/+]

Much has been said on both sides of the TAI-UTC in this thread in the
last few days.  Some people think our computers and NTP should maintain
time as TAI because either a) it's a philosophical issue or b) they know
of applications where accurate counting and timing of every second is
important.  Others think we should use UTC because either a) it's a
philosophical issue or b) they know of applications where matching legal
time is important.

I think the important thing, pointed out by some, is that there are
needs for both ways of tracking time and we need a mechanism to do
that.  Certainly changing from UTC to TAI just changes who is happy and
who isn't and makes a bunch of people change existing code (a la Year
2000) to accomodate it.

We then get into a chicken and egg discussion about why different
pieces  (UNIX, NTP, clocks, etc.) won't work one way or the other.
Ultimately, we will need every part of the implementation to accomodate
both TAI and UTC and that won't come quickly.  It would be useful,
though, to focus the discussion on what the final result might look like
and how to get from here to there.

It seems to me we need all of these:

1.  A time structure in each OS that tells us both TAI and UTC
2.  A way to tell the OS how we want to see the time
3.  A way to tell the OS whether we want to see 23:59:60 or to see a
clock running at half speed for two seconds starting at 23:59:59.0.
4.  An NTP that communicates both TAI and UTC in a robust way
5.  A procedure for reliably entering leap-second announcements into the
system, whether the hardware clock supports them or not.

I think we can attack the NTP piece now (while getting a jump on the
year 2038 problem :-)).  Maybe someday the OS vendors will follow along.

Jerry Brown


From: djb@koobera.math.uic.edu (D. J. Bernstein) [-/+]
Date: 19 Aug 1997 08:09:31 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions?
[-/+]
X-Keywords: synchronized
[-/+] TAI [-/+]

In article <33F8F6C3.3C7F@erols.com>, The Browns  <suneedle@erols.com> wrote:
> Others think we should use UTC because either a) it's a
> philosophical issue or b) they know of applications where matching legal
> time is important.

1. Legal time here in Chicago is not UTC. It's CST/CDT.

2. The NTP time scale is a bastardized version of UTC; it cannot be
converted reliably to UTC, TAI, or any other useful time scale.

3. Real systems are not synchronized to UTC, at least during leap
seconds; working applications cannot depend on time_t matching UTC.

4. Olson's time library already supports TAI time_t. It handles leap
seconds in localtime() and mktime().

> 1.  A time structure in each OS that tells us both TAI and UTC

This already exists. There's time_t for a numerical version of TAI, and
struct tm for UTC.

> 2.  A way to tell the OS how we want to see the time

This already exists. It's the TZ environment variable.

> 3.  A way to tell the OS whether we want to see 23:59:60 or to see a
> clock running at half speed for two seconds starting at 23:59:59.0.

What for? Who wants a half-speed clock?

> 4.  An NTP that communicates both TAI and UTC in a robust way

TAI is the crucial part. The OS already needs a leap-second table if it
wants to handle times correctly; the current TAI-UTC difference is
unnecessary if this table exists and insufficient if it doesn't exist.

> I think we can attack the NTP piece now (while getting a jump on the
> year 2038 problem :-)).

See http://pobox.com/~djb/proto/tai64.txt.

---Dan
Set up a new mailing list in a single command. http://pobox.com/~djb/ezmlm.html


From: robin@acm.nospam.org (Robin O'Leary) [-/+]
Date: 19 Aug 1997 11:20:47 +0100
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions?
[-/+]
X-Keywords: daylight
[-/+] GNU [-/+] IERS [-/+] implementation [-/+] RFC [-/+] TAI [-/+]

In article <33F8F6C3.3C7F@erols.com>, The Browns  <suneedle@erols.com> wrote:
>...
>I think the important thing, pointed out by some, is that there are
>needs for both ways of tracking time and we need a mechanism to do
>that.  Certainly changing from UTC to TAI just changes who is happy and
>who isn't and makes a bunch of people change existing code (a la Year
>2000) to accomodate it.
>We then get into a chicken and egg discussion about why different
>pieces  (UNIX, NTP, clocks, etc.) won't work one way or the other.

Everyone who wants change agrees that we need both standards.  This has
never been in dispute.  The only dissenters are those who want NTP to
continue only on UTC and somehow expect those who need TAI to make their
own arrangements to get it.  There are no circular arguments here.

>Ultimately, we will need every part of the implementation to accomodate
>both TAI and UTC and that won't come quickly.

I believe it can come quickly once NTP does its bit in distributing TAI
and TAI-UTC.  The GNU libc code already has all the necessary leap-second
handling stuff in ready, and with those two layers fixed, applications
should be completely unaware of the change.

>It would be useful,
>though, to focus the discussion on what the final result might look like
>and how to get from here to there.
A good plan.

>It seems to me we need all of these:
>
>1.  A time structure in each OS that tells us both TAI and UTC
Yes.  Perhaps it would be more explicitly accurate to say ``A time
structure from which both TAI and UTC may be calculated.''

>2.  A way to tell the OS how we want to see the time
The POSIX gettimeofday() is supposed to return seconds since epoch anyway,
so gives us TAI directly.  The conversion functions respect the setting
of the time-zone, so if we can treat TAI like an extra time-zone, the
user-level notification mechanism is already there.  I presume nobody
really wants to be able to ask for something like TAI+8+daylight saving
time, but if they do it just means creating copies of the relevant
UTC time-zones but omitting the leap-second conversion.

>3.  A way to tell the OS whether we want to see 23:59:60 or to see a
>clock running at half speed for two seconds starting at 23:59:59.0.
I don't think the latter should be an available option.  It is neither TAI
nor UTC, and I don't think we are in a position to justify the creation
of new timescales.

>4.  An NTP that communicates both TAI and UTC in a robust way
Rather, ``An NTP that can communicate any or all of TAI, UTC, TAI-UTC,
current or planned, in a robust way.''  That covers the four types of
information we may be able to acquire from refclocks or IERS.

>5.  A procedure for reliably entering leap-second announcements into the
>system, whether the hardware clock supports them or not.
Agreed.  Actually there are several issues here: remembering historical
leap seconds in a file so that the library time conversion code can
convert arbitrary times when it is asked for UTC, telling the kernel
the current TAI-UTC offset, and telling NTP to distribute notification
of TAI-UTC and future leap seconds.

>I think we can attack the NTP piece now (while getting a jump on the
>year 2038 problem :-)).  Maybe someday the OS vendors will follow along.
Agreed.

Who wants to help start a new RFC?

Robin O'Leary.
--
<robin@acm.org.nospam>  +44 973 310035  P.O. Box 20, Swansea SA2 8YB, U.K.


From: robin@acm.nospam.org (Robin O'Leary) [-/+]
Date: 19 Aug 1997 11:20:47 +0100
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions?
[-/+]
X-Keywords: daylight
[-/+] GNU [-/+] IERS [-/+] implementation [-/+] RFC [-/+] TAI [-/+]

In article <33F8F6C3.3C7F@erols.com>, The Browns  <suneedle@erols.com> wrote:
>...
>I think the important thing, pointed out by some, is that there are
>needs for both ways of tracking time and we need a mechanism to do
>that.  Certainly changing from UTC to TAI just changes who is happy and
>who isn't and makes a bunch of people change existing code (a la Year
>2000) to accomodate it.
>We then get into a chicken and egg discussion about why different
>pieces  (UNIX, NTP, clocks, etc.) won't work one way or the other.

Everyone who wants change agrees that we need both standards.  This has
never been in dispute.  The only dissenters are those who want NTP to
continue only on UTC and somehow expect those who need TAI to make their
own arrangements to get it.  There are no circular arguments here.

>Ultimately, we will need every part of the implementation to accomodate
>both TAI and UTC and that won't come quickly.

I believe it can come quickly once NTP does its bit in distributing TAI
and TAI-UTC.  The GNU libc code already has all the necessary leap-second
handling stuff in ready, and with those two layers fixed, applications
should be completely unaware of the change.

>It would be useful,
>though, to focus the discussion on what the final result might look like
>and how to get from here to there.
A good plan.

>It seems to me we need all of these:
>
>1.  A time structure in each OS that tells us both TAI and UTC
Yes.  Perhaps it would be more explicitly accurate to say ``A time
structure from which both TAI and UTC may be calculated.''

>2.  A way to tell the OS how we want to see the time
The POSIX gettimeofday() is supposed to return seconds since epoch anyway,
so gives us TAI directly.  The conversion functions respect the setting
of the time-zone, so if we can treat TAI like an extra time-zone, the
user-level notification mechanism is already there.  I presume nobody
really wants to be able to ask for something like TAI+8+daylight saving
time, but if they do it just means creating copies of the relevant
UTC time-zones but omitting the leap-second conversion.

>3.  A way to tell the OS whether we want to see 23:59:60 or to see a
>clock running at half speed for two seconds starting at 23:59:59.0.
I don't think the latter should be an available option.  It is neither TAI
nor UTC, and I don't think we are in a position to justify the creation
of new timescales.

>4.  An NTP that communicates both TAI and UTC in a robust way
Rather, ``An NTP that can communicate any or all of TAI, UTC, TAI-UTC,
current or planned, in a robust way.''  That covers the four types of
information we may be able to acquire from refclocks or IERS.

>5.  A procedure for reliably entering leap-second announcements into the
>system, whether the hardware clock supports them or not.
Agreed.  Actually there are several issues here: remembering historical
leap seconds in a file so that the library time conversion code can
convert arbitrary times when it is asked for UTC, telling the kernel
the current TAI-UTC offset, and telling NTP to distribute notification
of TAI-UTC and future leap seconds.

>I think we can attack the NTP piece now (while getting a jump on the
>year 2038 problem :-)).  Maybe someday the OS vendors will follow along.
Agreed.

Who wants to help start a new RFC?

Robin O'Leary.
--
<robin@acm.org.nospam>  +44 973 310035  P.O. Box 20, Swansea SA2 8YB, U.K.


From: James Youngman <JYoungman@vggas.com>
Date: 21 Aug 1997 16:07:02 +0100
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions?
[-/+]
X-Keywords: MVS
[-/+] TAI [-/+] update [-/+]

>>>>> "Nick" == Nick Maclaren <nmm1@cus.cam.ac.uk> writes:

  Nick> The important point that most conversions of time_t objects
  Nick> are not done using well-defined and standard interfaces.  They
  Nick> are both used as unique, increasing timestamps AND as the
  Nick> Unix/POSIX-mangled time since a virtual epoch.  And the second
  Nick> form is very often converted to and from other formats
  Nick> directly (i.e. not via the C library).

I really wish that time_t had not been specified to be an arithmetic
type.  There really isn't a very good reason for having it so.

  Nick> If you think that this is unreasonable, consider the problem
  Nick> of converting MVS TOD timestamps to Unix time_t - the former
  Nick> are long seconds (1.04576 seconds) since a different epoch!

At least, modulo leap seconds, this is unique.  OTOH, leap seconds are
the problem under discussuion.

  Nick> And then start considering what can be done with timestamps
  Nick> embedded in old files (e.g. file update times); it is CRITICAL
  Nick> to know whether they are TAI or UTC.

Mmm.

  Nick> Given the fact that POSIX has canonised the lunatic behaviour
  Nick> of broken C libraries, and the misbegotten half-UTC is used so
  Nick> much in external and data protocols, there is virtually no
  Nick> chance of changing to TAI.  This is a pity, but such is life

IMHO it's a hardware problem not a software problem.  The rotation of
the Earth should be stabilised with rockets.

Tidal wave?  What tidal wave?


From: nmm1@cus.cam.ac.uk (Nick Maclaren) [-/+]
Date: 21 Aug 1997 19:36:44 GMT
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions?
[-/+]
X-Keywords: calendar
[-/+] compatible [-/+] MVS [-/+] TAI [-/+] update [-/+]

In article <5ti237$okt@swan.ml.org>,
Robin O'Leary <robin@nospam.acm.org> wrote:
>In article <5thfk8$889$1@lyra.csx.cam.ac.uk>, Nick Maclaren
><nmm1@cus.cam.ac.uk> wrote:
>>Having both UTC and TAI at every layer would cause complete chaos, because
>>one application would write a timestamp using one and another would check
>>it using the other.  We already have this with local times.  The ONLY sane
>>way is to use TAI as the base clock, convert to UTC higher up and then
>>convert to local time in some applications.
>
>Having both UTC and TAI available is no more chaotic than having GMT,
>BST, PDT and all the other civil time conventions.  In any case, I
>propose having only TAI in the kernel, with libc converting to and from
>UTC whenever it would otherwise have performed a time-zone conversion.
>Applications that work in local time won't notice a change at all;
>those which only use ticks-since-1970 will work as they did before but
>now subtractions and comparisons will work properly across leap-second
>boundaries.

No, that won't work.  At present, there is only one ticks-since-1970
format used under Unix - adding TAI increases this to two.  You ARE
correct that the human-readable formats already have this ambiguity,
and it does cause complete chaos - try changing time zones between
level 0 and 9 dumps, and then doing a full restore!

The KERNEL and NTP could easily use TAI, but the problem is the result
of the time() function.

>The only applications which will behave differently are those which
>communicate tick values with other non-TAI machines, or those which
>convert from ticks to calendar time themselves.  The former should
>either fix their protocols or pass network-compatible values through
>converters---as we already must with ntohl/htonl; the latter are getting
>wrong answers whenever they compute times outside the current leap-second
>era anyway so probably justify the cost of fixing if accuracy is really
>important---and if accuracy isn't really important, well, they'll just
>give answers which are a few seconds wrong.

Please be serious.  There are hundreds of such protocols, few of which
have any capability for alternative versions - consider tar, cpio, rcp
and NFS alone.  At present, they are all consistent to within 1 second,
which is acceptable - you are proposing a 10-20 second variation.

>>The important point that most conversions of time_t objects are not
>>done using well-defined and standard interfaces.  They are both used as
>>unique, increasing timestamps AND as the Unix/POSIX-mangled time since a
>>virtual epoch.  And the second form is very often converted to and from
>>other formats directly (i.e. not via the C library).
>
>But POSIX-time is not suitable for use as an increasing timestamp,
>nor can it be accurately converted to UTC beyond a span of a year or two
>from the current time!
>
>>If you think that this is unreasonable, consider the problem of converting
>>MVS TOD timestamps to Unix time_t - the former are long seconds (1.04576
>>seconds) since a different epoch!
>
>To convert to TAI would be a subtract, a multiply and an add.  Not much
>of a problem surely?

No - for ONE program.  There are THOUSANDS of such programs.  My remark
was explaining why you idea of doing it in libc cannot be made to work.

>> And then start considering what can
>>be done with timestamps embedded in old files (e.g. file update times);
>>it is CRITICAL to know whether they are TAI or UTC.
>
>But we don't know what old time-stamps mean now!  There have been 22
>different POSIX-approved timescales so far since the adoption of UTC in
>1972, one for each leap-second (TAI+10, TAI+11,...TAI+31), and you can't
>know which of those timescales was used for each of your timestamps.
>If it had really been critical to you, you would have stored them in
>TAI anyway!

As I mentioned above, they are consistent to within 1 second.  Remember
that timestamps (as distinct from dates) are always produced using the
CURRENT timescale.

Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679


From: robin@acm.nospam.org (Robin O'Leary) [-/+]
Date: 22 Aug 1997 21:42:48 +0100
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions?
[-/+]
X-Keywords: TAI
[-/+]

In article <21@oldtimer.win-uk.net>,
Robin Kimberley <robk@oldtimer.win-uk.net> wrote:
>Surely what you suggest is more chaotic - at least with GMT, BST etc
>we are looking at whole hours only, whereas with TAI vs UTC we are
>messing with odd numbers of seconds.
It used to be just as easy to get hours (or half-hours in some parts of
the world) wrong as it is to get seconds wrong.  But we've had more years
of experience with clocks and watches which can show up this size of
error and consequently we have already made some engineering decisions,
such as keeping our clocks in POSIX-time, to help avoid those problems.
As our clocks get better, errors of 30 seconds or even fractions of a
second become more important.  That is, after all, why we run NTP.

>It is a similar problem to using GPS time vs UTC time.
GPS transmits the number of leap-seconds too, so it is possible to
convert between current GPS-time and POSIX-time.  Using only NTP to
obtain your time, even that isn't possible.

>If one was working in a closed environment, which didn't have to
>interface with the outside World...
...one would need a timescale which didn't depend on the input of
astronomers.

>...(which is slowing down guys)  it would be perfectly acceptable, and
>one could use any time scale one wanted:)
Not acceptable even then.  TAI would be the best choice.  POSIX-time has
ambiguous values in it and is therefore not suitable for any purpose
which requires accuracy of the order of one second.  And, as already
remarked, you can't use POSIX-time on an isolated computer because the
computer has to know where the leap-seconds are so it can leave them
out of its counting.

>Let's keep one universal time - UTC.
I have a better plan: let's keep one *really* universal time - TAI
(assuming the laws of physics governing hyperfine transitions really are
are universal).  Of course, for use with our current legal civil time
(UTC) and to achieve POSIX-compliance (shudder) we will also provide
appropriate conversion functions,

Robin O'Leary.
--
<robin@nospam.acm.org>  +44 973 310035  P.O. Box 20, Swansea SA2 8YB, U.K.


From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Tue, 19 Aug 1997 10:00:07 +0200
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Future Directions? (long)
X-Keywords: TAI
[-/+]

Robin O'Leary wrote:
[several paragraphs about how a consistent TAI timescale is better than
UTC]

> Agreed, it adds a layer of complexity.  However, mapping current time
> from TAI to UTC is child's play: you add a constant.  You have to get
> the constant from somewhere and that is potentially more difficult,
> but remember that NTP already does distribute instantaneous leap
> second information.  Compare that with the difficulty of implementing
> UTC correctly: how many programs that you use will let you enter the
> perfectly valid UTC time 23:59:60 and process it correctly?  Not many,
> I'm sure.  And ask any computer how old a file is in seconds and it's
> almost certain to tell you the wrong answer if it was created before
> the last leap second was added to UTC.  Writing a function to compute
> the number of seconds between two UTC times is not trivial because it
> requires two table look-ups, and most program I have seen to do this
> wrong or not at all!  Performing the same calculation in TAI is
> just subtraction.

I do agree that delta calculations in TAI seconds is very easy:

However, I don't believe anyone thinks TAI seconds (or UTC seconds or
Unix seconds_since_1970) is a very useful way to present time/date
information to humans.

If you want to keep all timestamps in TAI seconds, then you also need to
fix all program and library code that converts between YYYY-MM-DD
HH:MM:SS and (TAI/UTC/Unix) seconds.

If every program in the world used dynamic linking to an OS-supplied set
of conversion functions, then this would be feasible.

Currently, IMHO, it is not so.

Terje

--
- <Terje.Mathisen@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"


From: Richard Coleman <coleman@math.gatech.edu>
Date: 19 Aug 1997 04:51:56 -0400
[-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Building a better time protocol using TAI
[-/+]
X-Keywords: IERS
[-/+] TAI [-/+] update [-/+]

> > Who will maintain the TAI-UTC offset?
>
> That's a reasonable question. I would expect one person to watch IERS
> warnings and distribute a table of leap seconds in an easily parsed
> format (see, e.g., http://pobox.com/~djb/libtai/leapsecs.txt). All the
> stratum-1 servers would pick up the file every few months. After that
> it's up to the protocol.

We already have to do a similar task to update the list of
root name servers for your local name server.  I don't see why
doing this same task for the TAI-UTC offset is any harder.

I agree that using TAI as the basic measurement of time for
computer networks is a good thing.

Richard Coleman
coleman@math.gatech.edu


Next part