[AFS3-std] A call for consensus on draft-deason-afs3-type-time-02

[Russ Allbery]

Simon Wilkinson <simon@sxw.org.uk> writes:

> 2/ Choice of Epoch

> Russ makes some very good points about the dangers of using the MS
> Windows epoch. Given that the epoch is an arbitrary choice, I do wonder
> if it might be easier and safer to keep the Unix epoch for the new time
> type.

It's probably also the case, sadly, that even if we stick with the UNIX
epoch, we have to say something about leap seconds.  We may be able to get
away with using the same cop-out as POSIX, although most people in the
time community are fairly dissatisfied with the way POSIX discussed it:

    How any changes to the value of seconds since the Epoch are made to
    align to a desired relationship with the current actual time is
    implementation-defined. As represented in seconds since the Epoch,
    each and every day shall be accounted for by exactly 86400 seconds.

So, in other words, POSIX basically says that leap seconds don't exist as
separate seconds, and on days where there is an added leap second, all the
POSIX seconds of that day are actually 1.000012 SI seconds long.  This
means that time_t conversion is inaccurate around leap seconds, but once
you're past that day, you can do historical conversions back and forth
with UTC without having to think about them.

The alternative, where every second in the time representation corresponds
to a real SI second, is called TAI, and the problem with TAI is that
whenever you convert from TAI back to human time, you have to correct for
the number of leap seconds that have been added, which basically means you
have to keep a table of leap seconds around.

Is there prior IETF art here?  What does NFS say about leap seconds in
their timestamp specification?

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>