On Wed, Jul 27, 2011 at 8:32 PM, Derrick Brashear <[email protected]> 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. > > 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. Neither the actual data type, >> nor the definition of epoch used in AFS-3 is provided. That 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. 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 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. 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'). > > 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 point > 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 _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
