[tz] Fractional seconds in zic input

Tue Feb 6 14:46:52 UTC 2018

> Ah, I see our disconnect here.  I have no concern about the zic compiler.  The zic compiler is not in my workflow.  The *input* to the zic compiler is the *only* thing that concerns me.  I (and several others) have our own “zic compilers” which take this input, process it, and deliver it to our customers.  For us, the product of the IANA repository is only the tz database, and not the tz code.  Furthermore this “product”, the tz database, will be consumed by not just one alternative “zic compiler”, but many, and in many different languages on many different platforms.

This is not the disconnect, we're *both* talking about the input to zic. I was just saying that the current patch has no effect on the data, it's just a patch to the reference compiler (zic). What I don't understand is why you want to put *any* restrictions on the tzdb data precision at all. All your concerns about precision and range are irrelevant when you don't have sized inputs, all you're asking for is an arbitrary truncation of timezone offsets *at the source*, which is completely unnecessary. If you're writing your own compiler, truncate at 1ms or 1us or 1ns or whatever the precision of your offset data type is.

I will abandon my other line of argument about milliseconds not making sense because honestly I think the precision in the tzdb should be unlimited anyway, it's just lazy and short-sighted design to put an arbitrary limit on a DSL where that requirement makes no sense.

Re: Malcolm Wallace

> Since a 1-millisecond timezone offset corresponds to approximately
> 30cm longitudinal distance on the surface of the earth, I can't
> imagine any real (*timezone*) uses for better precision of the
> offsets.

I certainly don't think it's likely that any real time zone would use sub-millisecond precision, but I think it's much more likely that anyone uses an offset >= 1 year, which is why Howard's much-vaunted "range vs precision" argument should really not land us on milliseconds. That said, the one realistic scenario that I can immagine offhand that would have a strange offset like this (and this would honestly be something of an abuse of the tzdb notation to do this rather than a legitimate time zone) would be if someone encoded a leap second smear directly into their time zone by progressively adjusting their time zone during the course of a day or more. That might require some large amount of small entries with odd offsets. (Though honestly if someone does that, it would probably be best to add some sort of smear-specific notation to the tzdb).

Another possible scenario would be a strange aesthetic choice, like some small data haven country or religious organization starts operating in a time zone that has some symbolic value down to the nanosecond level (like an offset of 3:14:15.926535897). Again, this is very unlikely, but the pain it causes to support *any* precision in the *input* files is so mininmal (as long as we're changing up the format to support fractional seconds anyway) that it is not worth placing arbitrary restrictions on what kinds of time zones we can represent.

On 02/05/2018 10:31 PM, Howard Hinnant wrote:
> On Feb 5, 2018, at 9:02 PM, Paul G <paul at ganssle.io> wrote:
>>
>> My suggestion was that the input to the compiler (which is not strongly typed, so has no `sizeof`) should either have infinite precision or a clear upgrade path (e.g. a precision specification). So far Paul's patch has no effect on the *output* of the zic compiler, and I think it's at least reasonable for the tzdb (the *input* to zic) to be able to support arbitrarily fine inputs, considering that is the ultimate "source of truth", even without any of the other engineering concerns.
> 
> 
>>
>> With regards to the other engineering concerns, that was what I was trying to appeal to when I said that nanoseconds are a more reasonable choice for precision *if we're arbitrarily limiting this anyway*. By selecting milliseconds or even microseconds, you're sacrificing precision in exchange for completely unnecessary range. Time zone offsets outside of +/- 1 day are dubious (and unsupported in many environments), +/- 1 week are very unlikely, and +/- 1 year is absurd. While both are pretty unlikely, I think nanosecond precision offsets are much more likely than >219 year timezone offsets, so assuming that you want to truncate the inputs *at all*, it would be preferable to use nanosecond precision than millisecond. Honestly, I'm fine with (assuming infinite precision isn't supported) any resolution such that the range is ~1 week.
> 
> As I’ve repeatedly expressed, a precision of offset demands a precision in time point.  And it is the range of the time point, not the offset that concerns me.
> 
>     utc_offset == local_time - utc_time
> 
> This is an algebraic equation that _must_ be true.
> 
> If utc_offset has precision nanoseconds, then either local_time or utc_time must have precision of nanoseconds or finer to make this equation true.  This is a mathematical reality that exists.  If utc_offset == 1ns, and neither local_time nor utc_time have the ability to represent nanosecond precision, how can the above equation possibly work, aside from coincidental examples where the number of nanoseconds in the utc_offset is an integral number of the precision of local_time or utc_time (e.g. a billion nanoseconds if both local_time and utc_time are seconds precision)?
> 
> 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/20180206/7a0c4062/signature-0001.asc>