On 3/11/2011 12:13 PM, Andrew Deason wrote: >> I would be interested in hearing the use cases this is intended to >> address. > > There's the obvious initial difference where the code does/doesn't > support time with more granularity than 1s, but there's more than that. > Depending on the platform we're running on, our time source may have > different resolution, and if we receive time values from some other > source (such as disk), the resolution may vary. To be conservative in > calculating when events happen in a certain order, we need to know the > earliest and latest that an event may have occurred (since we may be > calculating whether something happened before event X, or after event > X). So, I don't think we can simply it down to a single timestamp.
If a FILETIME (100ns resolution) is read from disk, it is unknown what the actual resolution was that generated the value let alone whether the clock that generated the value is synchronized to that granularity with the one that is consuming it. My point is that it is impossible to know the granularity in this case. Transmitting additional granularity information doesn't help when it is unknown. The only time that it is possible to guarantee that X happened before Y before Z is if they were measured by the same entity (or at least measured against a common clock.) What use case is this actually going to help with? Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
