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

[Andrew Deason]

On Wed, 27 Jul 2011 17:10:45 -0400
Steven Jenkins <steven.jenkins@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.  If the
> proposed draft is accepted, when converting to proposed AFS timestamps
> from NFSv4 timestamps, information would be lost.

Personally, I don't find this to be worrisome, but I'm not adamant about
keeping this the same, either. If there is consensus about changing
this, then I'm fine with it.

I thought there were already concerns about inflating the width of time
fields to 3x their current size already, which is why I'm not just plain
agreeing. But I also wasn't too concered with the width increase anyway,
so... if someone wants to argue that, have at it :)

> The proposed RFC also does name the existing AFS time structure or
> provide information about beyond a description that it only supports a
> level of granularity down to a second.  Neither the actual data type,
> nor the definition of epoch used in AFS-3 is provided.  That should be
> remedied.

It's not consistent; there is no data type for "time" in the current
AFS-3 protocol, which I believe is mentioned in the last paragraph of
the introduction. The data type that gets used is mentioned there
(afs_int32), but the interpetation varies and it's not always clear to
even me when just looking at the XDR what they all are. We can say
something like they "usually represent the number of seconds since the
Unix epoch", but actually saying what it represents would involve
listing each RPC that makes use of any time-related field.

I think everything in current AFS-3 dealing with absolute time deals
with standard unix time like you'd expect (file mtimes, volume creation
times, etc), but there are (IMO) unclear uses of relative time, too.

> (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 did look for this, to see if they provided rationale for the epoch or
resolution, etc, but I couldn't find anything substantial. The only
thing I know of is MSDN documentation pages that just briefly mention
how it is time since 1601 in 100-ns increments.

> 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; thus, by adopting this
> RFC, AFS would have two different definitions for epoch depending on
> the time resolution used.  Given the confusion this might engender,
> and the change from the current AFS-3 and Unix definition of epoch, I
> suggest the definition of epoch not be changed.

I don't think we define epoch anywhere, and formal definitions of the
time fields don't exist. I'm fine with changing this, too, though, and
it's pretty easy to change. I don't have any real reasons for choosing
the current one; we just need to pick some time to base it on, and there
was another preliminary draft related to AFS time that used the windows
spec. I wasn't aware of any problems with it, so I didn't change that.

> Another issue is that the proposed AFSAbsTime and AFSRelTime data
> types are not both necessary.  Absolute 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').

I don't agree with this. Having a separate "relative" time makes it very
clear that we are _not_ dealing with time since an aforementioned epoch.
Making such a distinction makes mistakes caused by relative/absolute
confusion much less likely, as there are certain operations you can
prohibit based on type (adding 2 absolutes doesn't make sense,
subtracting absolutes yields a relative, etc). The only cost is three
letters in the type name.

-- 
Andrew Deason
adeason@sinenomine.net