Paul Eggert wrote:
>
> Their basic problem is that the UTC timescale is not appropriate for
> their applications. Their applications would work better with UTS.
>
Interesting. Do you mean that UTS should be used as an internal
timescale in a computer system, or do you propose that UTS is also
disseminated in some form, may be even as a replacement of UTC?
>
> > "By UTC convention, the adjustment happens at the end of a calendar day,
> > just before midnight. Upon reaching 24:00:00 that day, UTC is set
> > back by 1 s, effectively running again from 23:59:59 to 24:00:00."
>
> Technically speaking this is incorrect. First, as you probably know,
> the UTC markers are 23:59:59, 23:59:60, 00:00:00. Second -- and this
> is a more subtle point -- UTC is set back immediately after an
> inserted leap second, which means that if your clock has 86,400
> seconds per day (as is required for POSIX applications, for example),
> then it should tick 23:59:59, 00:00:00, 00:00:00. The POSIX clock is
> not set back to 23:59:59; it is set back to 00:00:00.
>
What you describe may be required by POSIX but it is wrong for UTC: the
second starting with the marker 23:59:60 is called "leap second" in UTC
and (more importantly) it belongs to June or December, not to July or
January. I quote from [ITU-R Rec. 460-4, section 2.2]:
"A positive leap-second begins at 23h 59m 60s and ends
at 0h 0m 0s of the first day of the following month."
See also [
ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.16] for the
dates during the last leap second.
>
> For an example of why monotonicity does not suffice, please see
> ISO/IEC 9945-1:1996 (POSIX 1003.1-1996), section 2.2.2.13, page 25,
> lines 488-498. This standard formally defines a day to be 86,400
> seconds. This assumption is not merely part of an international
> standard: it is hardcoded into a lot of real-world software, including
> some of the software that was used to deliver your message to this list.
>
I fully agree that 1 d = 86 400 s, no matter which timescale.
Actually, that is what I wanted to convey, but apparently did not.
Michael.
Received on Thu May 31 2001 - 04:02:10 PDT