tags 22033 + notabug close 22033 thanks Hi Zefram,
Zefram <zef...@fysh.org> writes: > I wrote: >> These two seconds are perfectly >>distinct parts of the UTC time scale, and the time-utc format ought to >>preserve their distinction. > > This is a problematic goal. At the time I wrote the bug report I didn't > have a satisfactory idea of how to achieve it, but I think I've come up > with one now. > > The essential problem is that the SRFI-19 time structure expects to > encapsulate a scalar value -- as it says, a count of seconds since > some epoch -- but there is no natural scalar representation of a UTC > time. Because of the irregularity imposed by its leaps, the natural > representation of a UTC time is a two-part structure, consisting of an > integer identifying the day and a fractional count of seconds elapsed > within the day. Because UTC days contain differing numbers of seconds, > this is a variable-radix system. More precisely, UTC days contain differing numbers of TAI seconds. However, they contain equal numbers of UTC seconds. I don't see how we can fix this given the definition of UTC. UTC, when represented as a number of seconds since some epoch, simply cannot represent leap seconds that cause UTC to jump backwards, as all leap seconds so far have done. This is an inherent problem with UTC, and is one of the reasons that TAI is more appropriate than UTC for many applications. Your objections here are valid, and cut to the heart of the long-standing debate over whether leap seconds are a good idea, a debate which continues today. If you're curious to read more on this, <https://www.cl.cam.ac.uk/~mgk25/time/#leap> is a good starting point. You might also be interested to know that your idea to encode leap seconds within the 'nanoseconds' field was also proposed by Markus Kuhn and mentioned by Olin Shivers on the SRFI-19 mailing list during the early discussion of SRFI-19: https://srfi-email.schemers.org/srfi-19/msg/2772123 It's an interesting idea, but I don't think it's something that we can unilaterally change in an existing, long-finalized SRFI. It would need to be part of a new SRFI, I think. So, I'm closing this as not-a-bug, although I acknowledge that the issue you raised is valid. Feel free to reopen and continue the discussion if you disagree. In any case, thanks very much for your many interesting and detailed bug reports, and I apologize for the long delay in addressing them. Regards, Mark
