On Feb 5, 2018, at 2:13 PM, Paul G <paul@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. Howard