[LEAPSECS] Leap second relationship to ISO 8601

[Brooks Harris]

Hi Tony,


On 2014-08-27 05:22 AM, Tony Finch wrote:
> Brooks Harris <brooks at edlmax.com> wrote:
>> Its important to note 8601 is silent on how "Daylight Savings Time" is handled
>> and provides no recommendation of how it might be indicated or represented.
> 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".

>
>> Looking closely you'll find there is no universal definition of "local time".
>> In particular, 8601 implies use of "offset from UTC", as indication of "local
>> time", but conflates this with Daylight Savings. 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? 2014-07-04T00:00:00-05:00 would have been correct in 
Chicago. We only know this because we know a-priori Daylight Savings was 
in effect in that jurisdiction. It was 2014-07-04T00:00:00-06:00 
"Mountain Daylight Time" while it was 2014-07-04T00:00:00-07:00 in 
Arizona, which does not observe Daylight Savings.

Strictly from the 8601 representation we don't know if Daylight was in 
effect or even if it is observed in the jurisdiction, so we can't 
distinguish the "fixed offset from UTC to the local jurisdiction".

Meantime POSIX (time) *does* record this distinction in STD and DST.

>
>> The definition of "proleptic UTC" is controvesial. NTP does the best job of
>> it. in my opinion, but watch out; its subtle.
> I did not think NTP had anything to say about proleptic UTC at all. Do you
> have a specific reference?

Network Time Protocol Version 4: Protocol and Algorithms Specification
http://www.ietf.org/rfc/rfc5905.txt

Section 6.  Data Types

" In the date and timestamp formats, the prime epoch, or base date of
    era 0, is 0 h 1 January 1900 UTC, when all bits are zero.  It should
    be noted that strictly speaking, UTC did not exist prior to 1 January
    1972, but it is convenient to assume it has existed for all eternity,
    even if all knowledge of historic leap seconds has been lost. "

This describes a proleptic UTC timescale that is *uncompensated for Leap 
Seconds*, that is, it extrapolates the Gregorian calendar counting 
method into the past from 1972-01-01T00:00:00Z (UTC).

Further, "Figure 4: Interesting Historic NTP Dates" shows that the NTP 
"prime epoch of era zero" is 2,272,060,800 seconds before 
1972-01-01T00:00:00Z (UTC).

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".

-Brooks

>
> Tony.