[tz] Fractional seconds in zic input

[Howard Hinnant]

On Feb 5, 2018, at 1:21 PM, Howard Hinnant <howard.hinnant at gmail.com> wrote:
> 
> On Feb 5, 2018, at 1:01 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:
>> 
>> In that case, how about if we follow POSIX's lead and specify nanosecond resolution as the highest the format supports? Although that's likely overkill, it does match a widely used standard; and better overkill than underkill.
> 
> On Feb 4, 2018, at 7:21 PM, Howard Hinnant <howard.hinnant at gmail.com> wrote:
>> 
>> In choosing a finest supported precision, I would encourage the choice of something coarser than nanoseconds.  Not only are there likely to not ever be any such real-world examples, but it is convenient to traffic in time points represented by signed 64 bit 2’s complement, which at nanosecond precision has a range of +/- 292 years (too small of a range imho). I think the finest practical precision would be microseconds (+/-292,000 years range), and even that is almost certainly overkill for any real-world example.

<sigh> I’m going to have to stop responding without completing my thought, sorry.

I should clarify that the precision of the UTC<->local_time mapping makes no theoretical limit on the finer side of the precision of the tools/clients that use said mapping.  For example, my library’s clients can traffic in nanosecond precision time stamps and still make good use of the today’s seconds-precision IANA UTC<->local_time mapping.

The precision of the IANA UTC<->local_time mapping creates a limit on the _coarseness_ of the client’s time stamp (assuming they want exact mappings), but it _does_not_ place a limit on the _fineness_ (I think I’m inventing words) of the client’s time stamp.  For example my client’s can not today traffic in time_stamps coarser than a second if they want to exactly represent time zone mappings, but they can traffic in time stamps finer than a second.

If the IANA mapping claims precision down to a nanosecond, then all downstream clients no longer have the option of trafficking in anything less precise than nanosecond precision.

The more I think about this direction, the worse it gets.

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/553ad658/attachment.sig>