[tz] Fractional seconds in zic input

Paul G paul at ganssle.io
Mon Feb 5 19:13:22 UTC 2018

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...

On February 5, 2018 6:58:52 PM UTC, Howard Hinnant <howard.hinnant at gmail.com> wrote:
>On Feb 5, 2018, at 1:50 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:
>> On 02/05/2018 10:46 AM, Howard Hinnant wrote:
>>> If two clients (different platforms) want to maintain the invariant
>that equal time_points remain equal after mapping, then they must
>operate at the precision of the mapping (or finer).
>> We already have clients that don't want to do that, as they discard
>sub-minute resolution. But I take your point that some clients may want
>to do that and we should cater to this subclass of clients too. In that
>case, how about if we stick to at most 1-ms resolution in the data, and
>note in zic.8 that 1 ms resolution is the way to go? I say "1 ms"
>because of Steve Allen's email.
>I can live with 1ms resolution.  However I do want to be clear:  We’re
>now no longer talking about a catastrophic mistake, but simply a
>mistake.  Your downstream clients will holler much more loudly than
>they did with the negative SAVE issue.  And the benefit is simply that
>we can model centisecond precisions for time stamps that are so old
>that could have only been measured with quartz technology at best.
>Having said that, I’ll shut up now, and thank you for the 1ms limit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180205/7da6c125/attachment.html>

More information about the tz mailing list