[tz] Fractional seconds in zic input

[Paul G]

> I want no truncation whatsoever.  I want to do exact time arithmetic.

Then why are you advocating for a 1ms precision? If you don't want any truncation, then you should be arguing for unlimited precision representations. Anything else will necessarily be a truncation.

> If I have an  offset of 1ns, and I add that to a time point of 1us UTC, the result is 1001ns in time zone X.  To be able to accurately represent the time point in Zone X I have to be able to exactly represent 1001ns.

True. This project does not decide what the time zones will be, though. You will have this problem if and only if some zone decides on an offset with nanosecond precision, and if that happens, tzdb will either have to truncate the real data to fit this arbitrary cutoff, or a second change to the precision supported will need to happen.

Of course it's unlikely that any zone will actually implement an offset with sub-millisecond precision, but I'm not buying arbitrarily limiting it to milliseconds on the *input* to the compiler on that basis.

> 
> 
> Howard
> 
> On Feb 5, 2018, at 4:03 PM, Paul G <paul at ganssle.io> wrote:
>>
>> Yes, but you are always necessarily truncating time to the precision of your representation because time has significantly greater than nanosecond precision. Your compiler can always truncate the offsets if you want to represent "point in time" as an offset from some fixed point (e.g. the unix epoch) and you want offsets *within that representation* to have the same precision as the offset you're using to represent the point in time. Given that the realistic range of offsets is on the order of +/- 1 day, I don't think we should limit their precision to the same precision as the timestamps they may be used with.
>>
>> If, as seems to be increasingly the case, we're concerned with future-proofing tzdb, it would make sense to support a very high precision like nanoseconds or go with a precision specification scheme that is effectively unlimited. Compilers are free to truncate to whatever level of precision they want in their output data.
>>
>> Best,
>> Paul
>>
>> On 02/05/2018 02:51 PM, Howard Hinnant wrote:
>>> 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: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/tz/attachments/20180205/773b647b/signature.asc>