During positive UTC leapseconds, typical date/time presentations of seconds "repeat" or "overflow" at the 60th second of a minute. We want to handle this somehow.
I think trying to present leapsecs in dates ("23:59:60") is a lost cause.
Upon reflection, its just a shorthand, a hack, which breaks consistency. Instants and Dates are meant to have 1-to-1 correspondence. Having two representations for one UTC instant requires a major set of hacks to the current design which isn't worth it.
To give an idea of such hack, we could introduce another field to date::date{}, say a boolean .leap field, which specifies that the embedded instant, if it were to hold values representing a positive leapsec, is either the "first" or "second" instance of the leapsec.
- How would date::add() work? Would it decide between incrementing .sec or toggling .leap? How would it even known when to check for leapsecs? Semantically, how is adding even reliable when it increments only some of the time?
- How does this generalize to other pairs of timescales with a different form of disambiguation (not leapsecs, something else)?
- How to convert a UTC instant to a date? Do we introduce yet another parameter to from_instant()? What about its error types for when conversions fail?
All of this smells like the cascading result of a fatal design flaw.
If one wants to make a clock which prints ":60" on positive leapsecs, just add to your for-loop a conversion from UTC to TAI and check for the leapsec, then account for it. You'd have to do that anyway, since such a clock would probably use a combination of network and monotonic time sources if it wants to be that accurate. Heck, maybe we could add that to hare-dateutil.