[LEAPSECS] Leap second relationship to ISO 8601

[Brooks Harris]

Hi Tony,

On 2014-08-27 12:08 PM, Tony Finch wrote:
> Brooks Harris<brooks at edlmax.com>  wrote:
>> On 2014-08-27 05:22 AM, Tony Finch wrote:
>>> ISO 8601 does not represent daylight saving nor time zones.
>> It can represent both, but incompletely, or ambiguously. The "time element"
>> called "zone designator" conflates "offset from UTC" and "Daylight Savings
>> offset" in the "time element" called "zone designator".
> The offset from UTC does not identify the time zone: many time zones can
> have the same offset. The offset does not tell you whether DST is in
> effect: you need to know the details of the time zone in order to work it
> out.

Yes, that's the point. You need to know many details which an 8601 
representation does not communicate.

>>>> For example, a date and time in New York City might be represented
>>>> as 2014-07-04T00:00:00-05:00 which misses the fact that Daylight was
>>>> in effect, or 2014-07-04T00:00:00-04:00 which misses the fact the
>>>> the fixed timezone offset is -05:00.
>>> The former is incorrect.
>> Incorrect where?
> The UTC offset in New York at that time was not -05:00 so that cannot be a
> time in New York.
Yes. But you only know that because you know the history of the Daylight 
Savings in that jurisdiction, again, not communicated by 8601.

>> Most explainations, and the spec itself, say that NTP does not account
>> for Leap Seconds, and it does not, *explicitly*. Note, however, that
>> 2272060800 secs / 86400 = 26297 days *exactly*. There were 10 Leap
>> Seconds in effect at 1972-01-01T00:00:00Z (UTC), so there must be 10
>> Leap Seconds in effect at the NTP "prime epoch of era zero", "0 h 1
>> January 1900 UTC".
> That reasoning is faulty.
I hope not :-\

> Figure 4 of RFC 5905 also says that the
> NTP timestamp for 1999-12-31 is 3155587200, and
> (3155587200-2272060800)/86400 is 10226 days exactly.
1999-12-31 is after 1972, and 32 Leap Seconds are in effect - 10 initial 
at 1972 plus 22 decreed inserts.

As Mills explains- http://www.eecis.udel.edu/~mills/leap.html

"Another way to describe this is to say there are as many NTP or POSIX 
timescales as historic leap seconds. In effect, a new timescale is 
reestablished after each new leap second. Thus, all previous leap 
seconds, not to mention the apparent origin of the timescale itself, 
lurch backward one second as each new timescale is established. "

The origin of this shifted NTP timescale on which 1999-12-31 is 
represented is 22 seconds before the original NTP "prime epoch". Thus, 
1999-12-31 (UTC) is 3155587222 seconds after the original NTP "prime 
epoch", but 3155587200 seconds after the *shifted* NTP origin in effect, 
which Figure 4 shows. The difference is 22 rather than 32 because 10 
Leap Seconds are in effect at the "prime epoch".

[ --------
Caution - Michael Deckers pointed out in an earlier email on the list 
(good catch!)-

   Please note that this table has to be read with caution.

   Besides the typo -678,491 for -678,941, one has to realize that
   "1 Jan -4712" is meant as a date in the Julian calendar, but
   all the other dates in column 1 must be taken as Gregorian calendar
   dates, even those before 1582-10-15 -- else the entries in
   columns 2,3,4 become incorrect. And this makes the entry
   in column 5 for the date 1582-10-04 incorrect.
------- ]

> You cannot infer the number of leap seconds between two NTP or POSIX
> time stamps, because both time scales handle leap seconds out of band.

Yes, all knowledge of leap seconds are lost in the counting mechanisms 
because of the NTP count "freeze" at the Leap Second insert (or 
over-count and reset for POSIX). Their origins shift with respect to the 
1972 UTC origin, the NTP "prime epoch", and the POSIX "The Epoch" 
("First day UNIX" in Figure 4) with each insert. I suppose you could 
call this "out of band".

-Brooks

> Tony.