On 10/6/22 15:45, Garrett Wollman via tz wrote:
C (intentionally) does not make any requirements on the encoding of a time_t, other than requiring that it be numeric. tzcode contains lots of complexity to deal with the numerous possible different realizations allowed by the C standard.
Despite its complexity, tzcode no longer supports every possibility allowed by the C standard. I removed support for floating-point time_t in 2013e, with the comment "It wasn't tested and probably never worked, no platform used it, and the latest POSIX no longer allows it."
(I haven't looked at recent C standards so I don't know if C allows time_t to be complex or decimal.)
In C23 time_t cannot be complex. It can be a decimal floating type, which would be problematic as mentioned above.
exactly 86,400 seconds long. (POSIX does not include tzcode's timegm() interface
This will change soon, as C23 will standardize timegm and POSIX will follow suit.
The practical upshot of this is that POSIX systems that implement leap seconds must tick the same second twice for a positive leap second, and must skip a tick if there is ever a negative leap second -- either way, making interval calculations inaccurate if performed in "seconds since the Epoch" rather than struct tm.
Leap smearing is reasonably popular. It also conforms to POSIX, with no duplicate or skipped ticks, and with intervals calculated the same way using time_t vs struct tm. However, it has a different set of problems.