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

[Russ Allbery]

Steven Jenkins <steven.jenkins@gmail.com> writes:

> The third (and most significant) concern is that the proposed draft
> proposes that the epoch be defined as January 1, 1601, rather than the
> traditional Unix epoch of January 1, 1970.  At a minimum, the rationale
> behind that choice should be explained in the RFC beyond the one
> sentence stating that the epoch definition comes from the Microsoft
> Windows FILETIME structure (also, should there be a cross-reference here
> to a Microsoft specification document?  I am concerned that we assert
> that definition to be true yet do not provide a normative reference for
> this.).

I apologize for having missed this previously, and appreciate Steven
raising this.  I'm also concerned about the use of this epoch.  While I
think that specifying that it's in UTC does make the epoch well-formed in
a technical sense, there are a lot of implementation landmines hidden in
that choice of epoch that worry me.

One issue is that on January 1, 1601 much of the Western world was on the
Julian instead of the Gregorian calendar.  Britain didn't adopt the
Gregorian calendar until 1752, for example.  This means that any
conversion of the dates included in this epoch range into a correct time
stamp will involve complex implementation issues that are beyond the scope
of what people usually realize they have to concern themselves with.  The
traditional epoch date of 1970 post-dates all these complexities.

Another is that the behavior of time with respect to leap seconds is
fairly well-understood (if considerably more weird than most people
realize) from 1970 onwards because it's explicit in POSIX specifications.
With an epoch before 1970, it's not clear to me that we would be able to
take advantage of those specifications.

I realize that this was probably chosen both because it predates any
conceivable file timestamp that someone may want to use in practice
(unlike 1970) and it's the epoch used by Microsoft Windows.  However, I'm
not aware of a public standards document that spells out these issues with
regards to Windows time the way that POSIX makes the details of these
issues explicit with regard to UNIX time.

I think it may be better to stick with a public standard epoch, rather
than using the Windows epoch, but at the least I think we need to say
something more about the implications of this choice for conversion, and
probably explicitly recommend that timestamps from some format other than
Microsoft FILETIME be derived by converting to UNIX time and then adding
116444736000000000 rather than attempting to convert directly to this
representation.

Also, note that this statement in this draft, while formally correct, is
somewhat deceptive:

    POSIX time values are also typically specified in terms of the amount
    of time that has passed since midnight 1 January 1970 UTC.

This is true definitionally, but "amount of time" here is not the amount
of time that you might expect.  Specifically, it's the amount of time in a
POSIX-specific "second" that is not actually one second long, due to the
impact of leap seconds.

Similarly, the document currently says:

   The AFSAbsTime type represents the amount of time that has passed since
   midnight or 0 hour January 1, 1601 Coordinated Universal Time (UTC).
   The value represents this amount of time in increments of 100
   nanoseconds (ns).

If applied literally, this means that all AFS timestamps will have to be
17 seconds different than the current POSIX time after subtracting
116444736000000000, since this specifies TAI timestamps, not a time in
UTC (whereas POSIX time is traditionally based on UTC).

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