On 7/29/22 00:03, Stephen Colebourne via tz wrote:
I see no value in adding sub-second precision to time-zone offset data beyond the comments. No system is likely to make practical use of it, and it is unlikely to be correct in most locations (is the plan to change LMT everywhere? if so why?) .
No there was no plan to change LMT everywhere, as the LMT values are somewhat arbitrary. The idea was only to write down standard time when it was standardized to be some non-integer offset from UT. Given the other comments in this thread I'm inclined to revert the effect of this change, so that vanguard form continues to use integer multiples of a second. So I installed the attached further patches, the last of which does the reversion. These patches keep the structured comments about subseconds, though. In the future some downstream client may find the subsecond info useful, and if so it should be easy to change vanguard form accordingly (it should be a one-line change to ziguard.awk). So it might be useful for other .zi parsers to parse and discard the subsecond information the same way that zic does (i.e., by rounding to even as documented in zic.8). It's conceivable (though unlikely) that in the future some impractical politicians may rebel against the Western concept of "Universal Time" and insist on a non-integer UT offset. Something like this happened briefly in Beijing in 1949 (which attempted to impose apparent solar time, Qing dynasty style!), and there was a milder echo in 2015 when the North Korean government rebelled against JST. If a Beijing-style revolution occurs somewhere in the future it would break a lot of software, ours included; but if the revolution's leaders merely choose a non-integer UT offset we'll have an easy fix for tzdata.