[LEAPSECS] Footnote about CCITT and UTC
As part of some research on a different topic, I came across a summary of the 1980 plenary meeting of CCITT, where appearantly the CCITT formally decided to switch from GMT to UTC. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Footnote about CCITT and UTC
In message: <10832.1229096...@critter.freebsd.dk> "Poul-Henning Kamp" writes: : : As part of some research on a different topic, I came across a : summary of the 1980 plenary meeting of CCITT, where appearantly the : CCITT formally decided to switch from GMT to UTC. that would make interesting reading. Is it available? Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Footnote about CCITT and UTC
In message <20081212.091847.-653353160@bsdimp.com>, "M. Warner Losh" writes : >In message: <10832.1229096...@critter.freebsd.dk> >"Poul-Henning Kamp" writes: >: >: As part of some research on a different topic, I came across a >: summary of the 1980 plenary meeting of CCITT, where appearantly the >: CCITT formally decided to switch from GMT to UTC. > >that would make interesting reading. Is it available? I checked and I think this may be referring to CCITT recommendation B.11: Recommendation B.11 Fascicle I.3 - Rec. B.11 LEGAL TIME; USE OF THE TERM UTC (Geneva, 1980) The CCITT, considering (a) that according to CCIR Recommendation 460-3 all standard-frequency and time-signal emissions should conform to Coordinated Universal Time (UTC); (b) that since 1972 UTC has been available as a worldwide time reference; (c) that in 1975 the General Conference of Weights and Measures (CGPM) recommended the use of UTC as the basis of civil time; (d) that other scientific organizations, particularly the International Astronomical Union (IAU) and the International Union of Radio Science (URSI) have recommended the general use of UTC; (e) that UTC enables the time of events to be determined with an uncertainty of 1 µs; (f) that according to CCIR Recommendation 536 and in accordance with the Recommendation of the General Conference of Weights and Measures the designation UTC is to be used in all languages; (g) that the World Administrative Radio Conference (Geneva, 1979) has decided that UTC shall be used in international radiocommunication activities; (h) that in accordance with Appendix 2 to the Telegraph and Telephone Regulations, Geneva, 1973 (relating to reciprocal exchange of information through the medium of the General Secretariat) Resolution No. 1 of these Regulations recommends Administrations inter alia to inform the Secretary-General of the legal time they apply. unanimously recommends that UTC should be used to designate the time in all other international telecommunication activities (including operational information) and in all service documents of the International Telecommunication Union. None of that is really interesting, except the very late date... Poul-Henning PS: According to Wikipedia, ISO 31-1 defines a day as 86400 seconds, anybody here who can verify if this is really the original text ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Footnote about CCITT and UTC
On Fri, 12 Dec 2008, Poul-Henning Kamp wrote: > > PS: According to Wikipedia, ISO 31-1 defines a day as 86400 seconds, > anybody here who can verify if this is really the original text ? ISO 8601-2004 cites ISO 31-1, and specifies several meanings for "day", one of which is equivalent to 86400 seconds. The ISO web site says that ISO 31 has been withdrawn and replaced by ISO 8 (published in 2006). ISO 31-1 and -2 are replaced by ISO 8-3. quote from ISO 8601-2004 ... 2.2 Time units, nominal durations and time intervals 2.2.1 second base unit of measurement of time in the International System of Units (SI) as defined by the International Committee of Weights and Measures (CIPM, i.e. Comite' International des Poids et Mesures) NOTE 1 See also ISO 31-1. NOTE 2 It is the base unit for expressing duration. 2.2.2 leap second intentional time step of one second to adjust UTC to ensure appropriate agreement with UT1, a time scale based on the rotation of the Earth [Rec. ITU-R TF.460-5] NOTE An inserted second is called positive leap second and an omitted second is called negative leap second. A positive leap second is inserted between [23:59:59Z] and [24:00:00Z] and can be represented as [23:59:60Z]. Negative leap seconds are achieved by the omission of [23:59:59Z]. Insertion or omission takes place as determined by IERS, normally on 30 June or 31 December, but if necessary on 31 March or 30 September. 2.2.3 minute unit of time, equal to 60 seconds [ISO 31-1] 2.2.4 hour unit of time, equal to 60 minutes [ISO 31-1] 2.2.5 day unit of time unit of time, equal to 24 hours [ISO 31-1] 2.2.6 calendar day time interval starting at midnight and ending at the next midnight, the latter being also the starting instant of the next calendar day NOTE 1 A calendar day is often also referred to as day. NOTE 2 The duration of a calendar day is 24 hours; except if modified by: -- the insertion or deletion of leap seconds, by decision of the International Earth Rotation Service (IERS), or -- the insertion or deletion of other time intervals, as may be prescribed by local authorities to alter the time scale of local time. 2.2.7 day duration duration of a calendar day NOTE The term "day" applies also to the duration of any time interval which starts at a certain time of day at a certain calendar day and ends at the same time of day at the next calendar day. Tony. -- f.anthony.n.finchhttp://dotat.at/ SOUTHEAST ICELAND: NORTHERLY OR NORTHWESTERLY 5 TO 7, OCCASIONALLY GALE 8 AT FIRST. VERY ROUGH OR HIGH. SQUALLY WINTRY SHOWERS. MODERATE OR GOOD. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Footnote about CCITT and UTC
In message , Tony Fi nch writes: >ISO 8601-2004 cites ISO 31-1, and specifies several meanings for "day", >one of which is equivalent to 86400 seconds. Wonderful confusion. It is insteresting that the militant 86400 second definition of ISO-31-1 only got superseeded once somebody tried to make UTC compliant with it :-) But if nothing else, it underscores how little attention people have paid to leap seconds... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Footnote about CCITT and UTC
Wonderful confusion. It is insteresting that the militant 86400 second definition of ISO-31-1 only got superseeded once somebody tried to make UTC compliant with it :-) But if nothing else, it underscores how little attention people have paid to leap seconds... It's hard to know how much or little attention without a baseline. Does anyone know much time ISO spends defining leap days, or does everyone just take them for granted? Is there official text on the definition. Another interesting point, based on press clippings alone, it would seem leap seconds get as much or more press as leap days. It appears that DST often generates grumbling but never a revolt, leap seconds a yawn or wink from the general public (except for those few of us who cringe), and leap days no argument at all from anyone. /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Footnote about CCITT and UTC
Poul-Henning Kamp wrote: >PS: According to Wikipedia, ISO 31-1 defines a day as 86400 seconds, >anybody here who can verify if this is really the original text ? Yes. ISO 31-1:1992(E) lists the following as units of time "which may be used together with SI units because of their practical importance or because of their use in specialized fields": NAME INTERNATIONAL OF UNIT SYMBOL FOR UNIT DEFINITION minutemin 1 min = 60 s hour h 1 h = 60 min = 3 600 s day d 1 d = 24 h = 86 400 s This is of course defining a *unit of measurement* called "day", not a calendar unit. Likewise the hour and minute. To be such, they are necessarily constant quantities. Calendar units have no such inherent constraint. I understand that astronomers similarly define a unit of time called "year", symbol "a", with value exactly 365.25 d = 31 557 600 s. (This is based on the mean Julian year.) This unit is not mentioned in ISO 31-1. The standard does mention the tropical year, as a unit of no status (listed for information only), but of course that's a different quantity with no such exact definition. It also lists (for information only) the light year, giving an approximate value that is sufficiently precise to show that it is based on the 365.25 d year rather than any other year. There is a problem with the symbol "d" for day: it means that the centiday (a very useful unit) clashes with the candela for the symbol "cd". SI itself avoids such clashes, and I'm slightly surprised to see ISO endorse these symbols without comment. -zefram ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Footnote about CCITT and UTC
Tom Van Baak wrote: >Does anyone know much time ISO spends defining leap days, >or does everyone just take them for granted? Is there official >text on the definition. ISO 8601 fully defines the Gregorian calendar, including the complete leap day rule. It says relatively little about leap seconds and UTC. The attitude of the standard is that leap days are an inherent part of the Gregorian-based date formats, but leap seconds are merely a peculiarity of one of many possible ways to count time of day. It's neutral about whether and when leap seconds may occur: that's an application issue. The timezone designators are specifically described as being relative to UTC, but it is more consistent with the rest of the standard to treat that mention of UTC as actually referring to vague UT. -zefram ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Footnote about CCITT and UTC
On Fri, 12 Dec 2008, Zefram wrote: > > [ISO 8601 is] neutral about whether and when leap seconds may occur: > that's an application issue. The timezone designators are specifically > described as being relative to UTC, but it is more consistent with the > rest of the standard to treat that mention of UTC as actually referring > to vague UT. 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. Tony. -- f.anthony.n.finchhttp://dotat.at/ LUNDY FASTNET IRISH SEA: NORTH BACKING WEST OR SOUTHWEST 3 OR 4, BUT 5 TO 7 AT FIRST IN LUNDY AND FASTNET, OCCASIONALLY 5 LATER IN IRISH SEA. SLIGHT IN IRISH SEA, OTHERWISE MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH IN FASTNET. SHOWERS. MODERATE OR GOOD. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Footnote about CCITT and UTC
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:
*time axis*
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:
*time scale*
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
same section:
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.
Section 4.2.2.1:
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:
*local time*
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:
*standard time*
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
Re: [LEAPSECS] Footnote about CCITT and UTC
On Sun, 14 Dec 2008, Zefram wrote: > > 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. Ah, yes, thanks for pointing that out, and also > *local time* > > 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. However... > 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. So non-UTC time has only minimal support by the standard. > 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. Yes, I think this kind of vagueness makes sense in a lot of situations (with appropriate caveats for applications that require subsecond precision and agreement between multiple systems). It would work for POSIX time too. Tony. -- f.anthony.n.finchhttp://dotat.at/ FORTIES CROMARTY FORTH: SOUTHERLY 5 TO 7, PERHAPS GALE 8 LATER. ROUGH OR VERY ROUGH, BECOMING MODERATE OR ROUGH. FAIR THEN RAIN. MODERATE OR POOR. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
