On 7/28/22 10:40, Steve Allen via tz wrote:
I urge that tz never attempt to encode zone offsets with precision better than 1 millisecond.
There's one instance of that in the patch, the "7:06:30.133333333" that comes from calculating 104° 17′ 17″ east of Paris Mean Time (00:09:21). The law in question gave a precision of 1 arc second for longitude, which works out to a precision of 66⅔ ms for UT offset. I used nine digits because POSIX timestamps have nanosecond precision, and so if tzcode ever gets support for non-integer UT offsets the closest POSIX approximation to legal time would need the nine digits. (POSIX timestamps do not indicate their precision, unfortunately.) There's a tension here between trying to make a potential POSIX implementation as close as possible, vs following the usual scientific practice where the number of digits indicates the precision and where "7:06:30.133333333" should presumably be replaced by "7:06:30.13" to reflect the 66⅔ ms precision. (Or should the last "3" be removed too? I'm a bit fuzzy on how best to express fuzziness when "X±Y" notation is not available....)