[tz] Fractional seconds in zic input

[Howard Hinnant]

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.

Howard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/tz/attachments/20180205/9c857014/signature.asc>