On 2/5/18 05:49, Stephen Colebourne wrote:

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
Reading https://www.iana.org/time-zones:

The Time Zone Database (often called tz or zoneinfo) contains code and data that represent the history of local time for many representative locations around the globe. It is updated periodically to reflect changes made by political bodies to time zone boundaries, UTC offsets, and daylight-saving rules. Its management procedure is documented in BCP 175: Procedures for Maintaining the Time Zone Database.

The tone of the referenced BCP is in line with that.

From the outset the data appears to have attempted to maintain an accurate picture of the history as well as current changes.

What any group may strongly desire isn't necessarily what was intended.

As earlier stated in another thread it's a simple task to filter the data to avoid problems with applications and operating systems and I'm guessing such a mechanism could be built into the current distribution.


 



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