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@gmail.com> wrote:
On Feb 5, 2018, at 1:50 PM, Paul Eggert <eggert@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. :-)

Howard