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

[Steven Jenkins]

On Wed, Jul 27, 2011 at 8:32 PM, Derrick Brashear <shadow@gmail.com> wrote:
...
>>
>> The seconds are the usual number of seconds since epoch, and the
>> nseconds is the offset based on the seconds in nanoseconds. =A0If the
>> proposed draft is accepted, when converting to proposed AFS timestamps
>> from NFSv4 timestamps, information would be lost.
>
> I disagree that we should devote the extra bits on the wire to
> preserve this extra
> information in the many cases a timestamp will appear on the wire
> given how few will
> have this extra information to "lose".

If the goal is to preserve underlying time information at a level so
that precision is not lost, then we need that precision.  If there is
a better way to preserve timestamp information at the level of
granularity of a nanosecond, please feel free to suggest something.

>
>> The proposed RFC also does name the existing AFS time structure or
>
> "does not"?

Correct.

>
>> provide information about beyond a description that it only supports a
>> level of granularity down to a second. =A0Neither the actual data type,
>> nor the definition of epoch used in AFS-3 is provided. =A0That should be
>> remedied.
>
> afs_int32, afs_uint32 are used sometimes interchangeably and sometimes
> incorrectly, so, what, you're like the draft to say that none was
> previously defined?
> because anything else would be untruth.
>

Adding some language to that effect would be very useful.  The
document needs more explanation of the legacy uses of time within
AFS-3 so that the impact of the proposed change can be put in context.

>>
>> 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. =A0At 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? =A0I am
>> concerned that we assert that definition to be true yet do not provide
>> a normative reference for this.).
>>
>> I may be speaking incorrectly here (I apologize for not having
>> researched this more thoroughly beforehand, but I wanted to get this
>> feedback out before the Call completes), but my recollection is that
>> AFS time defines epoch to be January 1, 1970;
>
> typically uses, but does not explicitly define.

Again, the RFC should document this.

...
>> Another issue is that the proposed AFSAbsTime and AFSRelTime data
>> types are not both necessary. =A0Absolute time can be represented as the
>> relative time since the epoch (and that would let us simplify the
>> names of the datatypes to something simpler such as 'afstime').
>
> disagree, and we beat this point seemingly to death a while ago.
> a relative time doesn't necessarily have anything whatever to do with
> the epoch, so once you've
> proposed going down the road of defining the epoch, now attempting to
> backfit a differential onto it by cheating the epoch to be the start poin=
t
> seems wrongheaded at best.
>

I was concerned that bringing this up would be rehashing old
arguments, but I was unable to find any discussion of this in the
afs3-standardization mailing list archives.

If those old archives are available in a public fashion somewhere, I
would be happy to review those before commenting further on this
section of the proposal.

Thank you,
Steven