[tz] Fractional seconds in zic input

[Stephen Colebourne]

Really? Another completely unnecessary change adding no value?

All consumers want is a file updated whenever a government changes the
clocks! Nothing more.

"Ideally tzcode would support fractional-second times and UT offsets
all the way down the chain" Why? What possible benefit could it bring
to the global software community.


"The real problem here is the incessant fiddling with the data. The
vast majority of users just want small stable updates representing
actual changes in time zones, not the continuous refactoring we've
been subjected to in the last few years."
http://mm.icann.org/pipermail/tz/2018-January/025822.html

"the focus should be on small, stable updates, not potentially
destabilizing "cleanups""
http://mm.icann.org/pipermail/tz/2018-January/025827.html

"any such change should have very, very clear ROI that strongly
outweighs the disruption"
http://mm.icann.org/pipermail/tz/2018-January/026087.html


Please stop messing around, revert this patch and abandon the idea.
TZDB needs to get back to being the pragmatic practical tool it was
intended to be.
Stephen




On 4 February 2018 at 16:37, 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.