[tz] Fractional seconds in zic input

[Michael Douglass]

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 
<https://www.iana.org/go/rfc6557>.

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 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180205/a8d1578c/attachment-0001.html>