# [time-nuts] FW: Bulletin C number 30

Magnus Danielson cfmd at bredband.net
Tue Jul 5 13:28:52 EDT 2005

```From: Warner Losh <imp at bsdimp.com>
Subject: Re: [time-nuts] FW: Bulletin C number 30
Date: Tue, 05 Jul 2005 10:58:32 -0600 (MDT)
Message-ID: <20050705.105832.74677930.imp at bsdimp.com>

Warner,

> > The main problem is that you can't directly get the UTC - TAI difference,
> > right? If you had that, then you could always convert between them.
>
> That's the crux of the matter.  With leap days, I know when to insert
> one for the next thousand years or so.  With leap seconds, I have no
> clue.  Not only that, I have no way to know the number of leap seconds
> that have happened between now and when the device was made unless I
> have some communications mechanism to the outside world to tell me.

What we really would need is an ISO-8601 like fashion to indicate the UTC-TAI
difference that the time was given in. So, even if a device have the wrong
UTC-TAI offset, you would be able to correct for it. However, that one should
have been in place ages ago to be useful.

Another useful thing would be a function that returns the UTC-TAI difference
at a given time.

> > There is
> > however a peculiarity of which I am sure you are aware of, you would still
> > need to know when the leap-seconds occured when doing time-differances over
> > possible leap-second insertion points. TAI(t2) - TAI(t1) may not be equalent
> > to UTC(t2) - UTC(t1).
>
> Yes.  that's the t1 - t2 problem that I'm talking about.  And the
> answer should be identical in both cases (because the leap seconds
> actually did happen).  The math is a lot easier if it is all done in
> TAI since you don't have to worry about leap seconds complicating the
> math.  Or the possible ambiguity that representing a UTC as a single
> number can bring with it.

As long as you convert your UTC measurement into the correct TAI that is.

I have noted that many UTC time signals only indicate that an leap second is
comming, instead of giving the difference. Loosing the history isn't nice, and
recovering from it may be less than trivial naturally.

BTW. I compared the wording in the description for time in ISO-C (1999) and
POSIX (latest online), and there is a peculiar difference between them,
supporting both camps. The POSIX reading only says it shall give the number of
seconds as the EPOCH. This means following TAI with no leap seconds. The ISO-C
reading states that it shall return the calender time, which could be
interprented as following UTC. However, then there is gmtime which both have
which should be used.

Anyway, I'm refreshing some neurons here and adding a few more connections
while at it.

Cheers,
Magnus

```