[LEAPSECS] Leap second relationship to ISO 8601

[Brooks Harris]

On 2014-08-24 07:03 PM, Gerard Ashton wrote:
> ISO 8601 is expensive; I obtained a copy before they started making it hard
> to find copies on the web. The wording of the standard is convoluted.

Yes it is, as is usually the case in standards due to the many voices 
that become part of it. In the case of 8601 this makes it difficult to 
identify the fact that it is *incomplete* in defining *comprehensive* 
date and time representation.

> Does
> anyone know if there is a highly-reputable, readable description of the
> standard that explains the extent to which the various choices are required,
> recommended, or merely allowed?

8601 is famous for its form(s) of character representation, especially 
its recommendation of the order being "most significant first" - 
YY-MM-DD hh:mm:ss. Yet perhaps its more important contribution is 
defining the date and time data elements it is representing.

But keep in mind it is all recommendation - there's no requirement of 
anything. Folks probably overlook the paragraph in the Scope -

"This International Standard does not assign any particular meaning or 
interpretation to any data element that
uses representations in accordance with this International Standard. 
Such meaning will be determined by the
context of the application."

8601 goes a long way toward defining the time and data elements, but it 
is unfortunately incomplete. Note it relies in turn, and normatively, on 
the IEC *vocabulary* documents, themselves even more obscure and 
difficult to obtain. (Throughout 8601 you'll notice references like 
"[IEC 60050-111]").

Studying this chain of provenance is also convoluted, and the upshot is 
to recognize how distressingly incomplete the underlying terms and 
definitions are, especially in regards to specifying "local time".

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

Typically 8601 is interpreted as adhering to the "rules of UTC" 
(although, strictly, this too is not required). 8601 gives a brief 
definition of UTC, but the careful implementer will look to the 
literature to better understand it. Here you find a large number of 
standards bodies and specifications which together define "UTC". It is 
much more convoluted and complex than 8601. It has been characterized as 
"fractured". You may start with ITU RECOMMENDATION ITU-R TF.460-6, which 
will lead to the BIPM Annual Report on Time Activities, and to 
INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS), 
Bulletin C, amongst others. The deeper you go, the more complex it gets.

Add to this POSIX (time), the underlying heritage of most computer-based 
timekeeping systems. Note that POSIX's notion of "local time" is 
actually in direct conflict with the international standards. IEC 60050 
(and 8601) say that "Standard time" may or may not include "Daylight 
Savings" (or "summer time"), while POSIX separates them as STD and DST. 
This is better, that is, closer to "common use", but there are other 
deficiencies and ambiguities in the POSIX spec, especially regarding the 
definition of "The Epoch" and counting methods with regard to Leap Seconds.

Enter NTP. The NTP spec can be used to partly clarify Epochs and 
handling of Leap Seconds, but it too has deficiencies in Leap Second 
counting.

> For example, if one wishes to use the format 2014-08-24, is it mandatory
> that the day begin at midnight according to some unspecified local time?
>
> If one wishes to specify the time, does the standard recommend 23:02Z over
> 07:03, or are they on an equal footing?
>
> Is there a highly respected discussion anywhere of what to do about UTC
> before leap seconds, or the period before the introduction of UTC, in ISO
> 8601 representations?

The definition of "proleptic UTC" is controvesial. NTP does the best job 
of it. in my opinion, but watch out; its subtle.

Many efforts have been made to resolve these ambiguities, none 
universally accepted. See, for examples -

Date-Time Vocabulary (DTV) Version 1.0
http://www.omg.org/spec/DTV/1.0/PDF/

Time Ontology in OWL
http://www.w3.org/TR/owl-time/

All tolled, I think this is a pretty good characterization of the state 
of the art -

The Problem with Time & Timezones - Computerphile
https://www.youtube.com/watch?v=-5wpm-gesOY

-Brooks
>
> Gerry Ashton
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs
>
>