[tz] Fractional seconds in zic input
howard.hinnant at gmail.com
Mon Feb 5 21:47:04 UTC 2018
Allow me to try again:
I want no truncation whatsoever. I want to do exact time arithmetic.
If I have an offset of 1ns, and I add that to a time point of 1us UTC, the result is 1001ns in time zone X. To be able to accurately represent the time point in Zone X I have to be able to exactly represent 1001ns.
On Feb 5, 2018, at 4:03 PM, Paul G <paul at ganssle.io> wrote:
> Yes, but you are always necessarily truncating time to the precision of your representation because time has significantly greater than nanosecond precision. Your compiler can always truncate the offsets if you want to represent "point in time" as an offset from some fixed point (e.g. the unix epoch) and you want offsets *within that representation* to have the same precision as the offset you're using to represent the point in time. Given that the realistic range of offsets is on the order of +/- 1 day, I don't think we should limit their precision to the same precision as the timestamps they may be used with.
> If, as seems to be increasingly the case, we're concerned with future-proofing tzdb, it would make sense to support a very high precision like nanoseconds or go with a precision specification scheme that is effectively unlimited. Compilers are free to truncate to whatever level of precision they want in their output data.
> On 02/05/2018 02:51 PM, Howard Hinnant wrote:
>> On Feb 5, 2018, at 2:13 PM, Paul G <paul at ganssle.io> wrote:
>>> Maybe I'm missing something, but are we talking about fractional seconds in *offsets* or fractional seconds for the time of the change?
>>> For offsets, why would we care whether it can represent +/- 292,000 years, since it's fantastically unlikely that a time zone offset would even be outside of +/- 24 hours. While both outcomes are very unlikely, I think an offset best represented in nanoseconds is much more likely than an offset +/- 292 years...
>> Let’s say, just for example, that we have a UTC offset of 1ns for Zone X.
>> Let’s further assume that I want to map arbitrary time points between UTC and X, exactly.
>> Well, in order to be sure that I can map UTC to X and back to UTC again, with no loss of information, then time points in both UTC and in X must have nanosecond (or finer) precision. (disclaimer: I’m using the term “finer” here in a very coarse manner. :-) The actual requirement is that the precision of the UTC and X time points must be able to exactly represent nanosecond precision, in the same way you can exactly represent minutes precision with a type holding milliseconds precision — but not vice-versa.)
>> If I can only represent (for example) microsecond precision in UTC and X, then when I map a time point from UTC to X (or vice-versa), the 1ns offset will be lost when I add it to a count of microseconds, and truncate the result to microseconds. Subsequently my X time point will not be an accurate representation of the specified mapping for the X time zone. For example if I subtract UTC from local time I should get the offset, but in this example I would get 0.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Message signed with OpenPGP
More information about the tz