<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 2/5/18 05:49, Stephen Colebourne
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACzrW9DvCR0hNYytbu-xjHCLLmp2tqsLPuzZO6DDhpG+7DJhdQ@mail.gmail.com">
<pre wrap="">
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
</pre>
</blockquote>
Reading <a class="moz-txt-link-freetext" href="https://www.iana.org/time-zones">https://www.iana.org/time-zones</a>:<br>
<br>
The Time Zone Database (often called <tt>tz</tt> or <tt>zoneinfo</tt>)
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 <a
href="https://www.iana.org/go/rfc6557">BCP 175: Procedures for
Maintaining the Time Zone Database</a>.<br>
<br>
The tone of the referenced BCP is in line with that.<br>
<br>
From the outset the data appears to have attempted to maintain an
accurate picture of the history as well as current changes. <br>
<br>
What any group may strongly desire isn't necessarily what was
intended. <br>
<br>
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.<br>
<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CACzrW9DvCR0hNYytbu-xjHCLLmp2tqsLPuzZO6DDhpG+7DJhdQ@mail.gmail.com">
<pre wrap="">
On 4 February 2018 at 16:37, Paul Eggert <a class="moz-txt-link-rfc2396E" href="mailto:eggert@cs.ucla.edu"><eggert@cs.ucla.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>