<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">I too wonder about the wisdom of this.<br>
<br>
Tzdb has been one-second resolution for decades. This has proven
to be sufficient and acceptable for "civil time". I know of no
call for higher resolution for local time. I'm all for better
precision where needed, but I think this adds new complexity and
risks interoperability issues. I see several difficulties that
recommend against it.<br>
<br>
I think there could be significant controversy choosing a decimal
fraction resolution. Steve Allen says it would be better to limit
to milliseconds. I'd point out that DUT1 was decided to be 1/10th
second because this was sufficient for celestial navigation at the
time. Paul has mentioned many systems can represent nanoseconds,
but Windows is 100-nanoseconds. European financial regulations
call for 50 microseconds. Paul has now rounded to centisecond. So
which is it? Should tzdb support *variable* resolution? <br>
<br>
In the work I'm doing for media (video/audio) representation we
have some strange rates, or frequencies, to cope with, including
30000/1001 video and 48000/1 audio. Here we need *exact* integral
counts of media units since the IEEE 1588 PTP "Epoch". This is
tricky business to implement. A critical factor is determining
'start-of-day' (midnight) of local time. Thankfully Tzdb provides
one-second resolution representation of local time rules. If this
were to change it would greatly complicate these calculations.<br>
<br>
Also, I am supporting Vanguard (negative DST amongst things), and
I'm doing this with versions of zic and zdump that I've ported to
Windows, including parts of glibc. If these sorts of changes are
made to the tz data and zic it will require merging those changes
into my implementation and retesting tens of thousands of data
points.<br>
<br>
I think this could possibly confuse policy makers about how best
to define their local times in laws, etc. It could also tempt
somebody to adopt sub-second offsets in their local time. This
could open tzdb to yet another avenue of 'political' critique.<br>
<br>
I've great respect for Paul's skills and dedication and his
instinct to be as true to the historical record as possible. But I
think this is a bridge too far.<br>
<br>
"A second never lies".<br>
<br>
-Brooks<br>
<br>
On 2022-07-29 3:26 AM, Jon Skeet via tz wrote:<br>
</div>
<blockquote
cite="mid:CA+5fHt+-e_bujDJvsiZecUiT1TJrDsy+E=Y_PHA-xVP6EAvWtA@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<div dir="auto">
<div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, 29 Jul 2022, 08:04
Stephen Colebourne via tz, <<a moz-do-not-send="true"
href="mailto:tz@iana.org" target="_blank"
rel="noreferrer">tz@iana.org</a>> wrote:<br>
</div>
<blockquote class="gmail_quote">FWIW, while I'm content that
this is for Vanguard only, I don't<br>
personally think this change should be made.<br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">I second this. From the perspective of Noda Time
(the project I maintain) we decided long ago that the
precision of UTC offsets would be one second.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Basically this change will mean extra work for
me to truncate back to seconds. (I'm pretty sure we're using
the vanguard data - I'd need to double check.)</div>
<div dir="auto"><br>
</div>
<div dir="auto">Obviously the small inconvenience for one
developer shouldn't be regarded as a veto, but I wanted to
mention it as one data point. There are definitely costs to
this - are there also known concrete benefits, in terms of
consumers wanting to use this data?</div>
<div dir="auto"><br>
</div>
<div dir="auto">Jon</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote"><br>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>