[Ietf-calsify] definitive references for UTC
mikesamuel at gmail.com
Tue Mar 27 13:24:55 PST 2007
Most existing date libraries ignore leap seconds, so it's unlikely
that systems built on these will handle them.
I don't think that 2445 uses a <units-since-epoch> representation of
dates, so the only place where UTC enters the picture is in durations
-- subtracting dates, and adding durations to dates. One alternative
to specifying a different interpretation of UTC, would be to mandate
that PT60S == PT1M.
Here's a quick survey of leap second support in common platforms/libraries:
Distributing leap second tables and requiring hosts to be "on-line"
to receive them in those days (when UUCP over slow baud modems was
common) was not considered realistic. It was felt expect vendors
and/or system administrators to maintain a complete leap second table
(including leap seconds announced in advance) was also considered
The POSIX decision was to preserve existing practice. That the
vast majority of time-stamp calculation methods ignored leap seconds .
The decision was to to continue to use a trivial seconds since the
Epoch" calculation that ignored leap seconds.
Joda-Time does not support leap seconds. Leap seconds can be supported by
writing a new, specialized chronology, ...
Note that on non-POSIX systems that include leap seconds in their
notion of a
timestamp, leap seconds are ignored by fromtimestamp().
Similarly java.util.Date only supports leap seconds if the underlying
On 26/03/07, Bill Kearney <wkearney99 at hotmail.com> wrote:
> > Although it's tempting to make one
> > protocol shoe fit multiple application feet, the result is rarely
> > satsifactory and usually is a wretched compromise that serves nobody.
> Ietf-calsify mailing list
> Ietf-calsify at osafoundation.org
More information about the Ietf-calsify