[tz] Fractional seconds in zic input

[Howard Hinnant]

On Feb 4, 2018, at 7:21 PM, Howard Hinnant <howard.hinnant at gmail.com> wrote:
> 
> On Feb 4, 2018, at 11:37 AM, Paul Eggert <eggert at cs.ucla.edu> wrote:
>> 
>> For many years I've chafed at tzdata's lack of support for fractional seconds. We have good evidence of well-established standard-time UT offsets that were not multiples of one second; for example, the Netherlands before 1937. These can't be recorded in tzdata except as comments.
>> 
>> Ideally tzcode would support fractional-second times and UT offsets all the way down the chain. This would mean changes to the tz binary format and to the runtime API, though, which is not something we'd do lightly, if ever. However, it's easy to change the zic spec to allow fractional seconds, and to change zic to accept and ignore the fractions, so that fractional seconds can be documented more formally in the data; this could well be useful to applications other than tzcode. Proposed patch attached, hairy sscanf format and all.
>> 
>> This patch does not actually change the data, as we'll need time, and/or a procedure to automatically generate data compatible with zic 2018c and earlier.
>> <0001-Add-fractional-seconds-to-data-format.patch>
> 
> If we are to add fractional second support, it should come with a specification of the precision, or precision-range that is supported (e.g. centiseconds, milliseconds, whatever).  Without such documentation, 3rd party zic compilers will have to make an assumption based on the finest precision example in the data file, which may subsequently break when a finer-precision example is later introduced.  To require compilers to support arbitrarily fine precision chosen at run time is neither practical nor terribly useful.
> 
> 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.
> 
> Also, do you anticipate a similar refinement of the “SAVE” quantity?  Currently the finest precision given is minutes.  I don’t currently recall if that precision is specified, or is simply a de-facto standard.
> 
> If such changes to the database are to be made, I would much prefer they be made asap.  Syntax and semantics changes to the database are a much bigger deal to me than changes to zic.  And I am in midstream of attempting to base an international C++ language standard on the syntax and semantics of this database.  “Optional support” of things such as UTC offsets with centisecond precision are undesirable as it will lead to non-portable behavior for such things as equality of time points.  The finest representable precision of a UTC offset should be a concrete, portable specification.

I should’ve added two things:

1.  Remember when I gave an early warning that negative SAVES’s would break things? (http://mm.icann.org/pipermail/tz/2017-December/025694.html).  This change to the database will make that change look like a walk in the park.

2.  Doing this without specifying a maximum precision will mean the substantial breakage I speak of in 1) will happen every time the precision is increased.

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/840f481a/signature.asc>