[LEAPSECS] Footnote about CCITT and UTC
zefram at fysh.org
Sun Dec 14 16:57:55 EST 2008
Tony Finch wrote:
>I can't see anything in ISO 8601-2000 or -2004 that supports "vague UT".
>Both versions of the standard are quite specific about times of day being
>UTC or at a specific offset from UTC.
Quoting from ISO 8601:2004(E). Start with the most fundamental
definition, section 2.1.1:
mathematical representation of the succession in time of
instantaneous events along a unique axis
The time axis, for the purposes of the standard, does not need to
correspond to the physical proper time of any reference frame, nor to
a best-effort realisation of such an axis. Section 2.1.4:
system of ordered marks which can be attributed to instants on
the time axis, one instant being chosen as the origin
These marks are not required to correspond linearly to physical proper
time. Indeed, there are no particular restrictions on the marks.
This is made clear in the next part of the same section:
NOTE 1 A time scale may amongst others be chosen as:
-- continuous, e.g. international atomic time (TAI) (see IEC
60050-713, item 713-05-18);
-- continuous with discontinuities, e.g. Coordinated Universal
Time (UTC) due to leap seconds, standard time due to summer
time and winter time;
I don't want to get into the debate about whether a leap second
constitutes a discontinuity, but it's clear that this is a fairly broad
concept of time scale.
Now, look at the scope of the time-of-day formats. Section 4.2.1:
This International Standard is based on the 24-hour timekeeping
system that is now in common use.
This, the primary statement of how the standard approaches time of day,
is about how the time of day is expressed. It does not indicate any
concern about which time scale defines those hours. At the end of the
NOTE These expressions apply to both UTC and non-UTC based time
scales for time of day.
This seems to be the crucial bit that you missed. It's explicit about
allowing time scales other than UTC, and doesn't restrict the choice
of time scale at all. UT1, with strict 86400-second days, is obviously
permitted, and I suggest that vague UT per se is also a valid time scale.
In the representations of local time as defined below no
provisions have been made to prevent ambiguities in expressions
that result from discontinuities in the time scale of local time
(e.g. daylight saving time).
That is, local time is a type of time scale. A particular local
time may be a time scale with discontinuities, and in particular gross
discontinuities. This is consistent with the definition in section 2.1.4.
Furthermore, putting these last two together, it is strongly implied
that a local time scale does not need to be based on UTC. This is made
explicit by the definition in section 2.1.16:
locally applicable time of day such as standard time of day,
or a non-UTC based time of day
You're permitted to represent, for example, the mean-solar-time-based
British legal time in ISO 8601.
The parts that are specific about using UTC and offsets therefrom begin
with the definition in section 2.1.14:
time scale derived from coordinated universal time, UTC, by a time
shift established in a given location by the competent authority
This is not defining local time per se, but "standard time", which is
evidently a subtype of local time. The definition of "local time",
quoted above, is actually referring to this definition to indicate a
permitted type of local time. (You might have noticed inconsistent
capitalisation of the full name of UTC. This is as in the standard.)
Section 4.2.5 ("Local time and Coordinated Universal Time (UTC)")
is about representing the difference between local time and UTC.
It doesn't actually use the term "standard time", but clearly for the
difference to be exact the local time must be a standard time as defined
in section 2.1.4.
The other representation that is defined specifically by reference to
UTC is in section 4.2.4 ("UTC of day"). This is about the use of "Z"
to tag a time-of-day as being on the UTC time scale.
So, if we follow the standard as written, I can validly (in ISO
8601) state that the BST (British Summer Time, = GMT + 1h) time is
"22:32:12.123", but I can't write it as "22:32:12.123+01:00" or describe
BST as "+01:00". The offset from UTC to BST is not exactly one hour,
but some constantly-changing value that is best determined by the IERS.
Likewise, I can write the GMT time, which is the legal time in Britain,
as "21:32:12.123", but not as "21:32:12.123Z", because GMT is not
precisely UTC. (I'm using "GMT" in the strict sense here, of course.)
Unfortunately ISO 8601 does not supply any way to designate UT1 or any
other flavour of UT except UTC. Thus, strictly speaking, there is no
way to designate any local time that is based on UT1 rather than UTC.
As we know from previous discussions on this list, there are quite a few
such time scales with current legislative endorsement. (And a few that
can't decide which they're based on.)
It seems to me that the standard would be rather more useful if "standard
time" were defined more according to its original meaning: a local time
scale defined by an offset from UT, rather than specifically from UTC.
The timezone designation material should correspondingly refer to UT
rather than UTC, and the "Z" should probably follow by designating UT.
All of these would be explicitly vague as to which flavour of UT is
being referred to.
With this change, UTC-based and UT1-based local time scales are both
subtypes of standard time, and both can be described to equivalent
precision using the standard timezone designators. It is true that
the timezone designators would lose their current notional sub-second
precision, but it seems more important to be able to describe the
grosser features of a local time scale first. Possibly there should
be an additional type of designator, added to the standard, to identify
flavours of UT.
In the last three paragraphs above I'm playing Fantasy Standards.
But actually in practice the timezone designators *do* get used to
describe relations to UT1 and vague UT, not just UTC. So the change that
I propose would not only make the standard formally more applicable but
also bring the theory and practice closer together.
More information about the LEAPSECS