[tz] POSIX epoch in the news?

Brian Inglis Brian.Inglis at systematicsw.ab.ca
Mon Feb 15 03:54:41 UTC 2016


On 2016-02-12 20:28, Paul Eggert wrote:
> The bug reportedly affects only 64-bit platforms. Perhaps some part of the OS X boot process naively iterates from time stamps starting from 1970 up through "now", and treats 1969-12-31 UTC as a very large (perhaps unsigned) time stamp. On a 32-bit platform there are only 4 billion time stamps or so, so even a naive approach could work in a reasonable amount of time; a 64-bit platform, though, would have about 4 billion times more work to do, and users understandably don't want to wait that long.
> If we were designing POSIX from scratch, perhaps we could let (time_t)0 denote the Big Bang. Then, iPhone users would need to set the date to ~13,798,000,000 BCE to expose the bug. Nobody would have the patience to do that, since the UI forces them to scroll back year-by-year to the desired date. Problem solved!

Specifying mktime(3) result (time_t)-1 as the error flag where time_t is signed always struck me as a nasty discontinuity on the day before the Unix epoch.
Specifying either INT_MAX or UINT_MAX depending on the signedness, and maybe a nice symbol like E_TIME_T, would have reduced the range by all of a second, but also reduced the chances of these naive bugs having much impact, as that big blob of UPPERCASE could act as a clue stick, whereas -1 can be missed on a quick scan.
For time(3) result (time_t)-1 meaning time is unavailable is reasonable, but again {,U}INT_MAX could also have been used for consistency.
The C and POSIX standards still have a few of these cases where magic numbers are not defined as symbols lurking in their dark corners.
Either programmers have to define their own symbols, each differently, or specify a constant, and maybe also a comment, if their maintainers are lucky!

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada


More information about the tz mailing list