[tz] [PROPOSED 3/3] Vanguard form now uses subsecond precision

[Brooks Harris]

I too wonder about the wisdom of this.

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.

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?

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.

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.

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.

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.

"A second never lies".

-Brooks

On 2022-07-29 3:26 AM, Jon Skeet via tz wrote:
> On Fri, 29 Jul 2022, 08:04 Stephen Colebourne via tz, <tz at iana.org 
> <mailto:tz at iana.org>> wrote:
>
>     FWIW, while I'm content that this is for Vanguard only, I don't
>     personally think this change should be made.
>
>
> 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.
>
> 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.)
>
> 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?
>
> Jon
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20220729/cc6acadf/attachment.htm>