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@iana.org <mailto:tz@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