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
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
