[tz] New Yorker article on David Mills and NTP

Paul Eggert eggert at cs.ucla.edu
Fri Oct 7 01:34:11 UTC 2022


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.



More information about the tz mailing list