Hacker News new | ask | show | jobs
by usrnm 547 days ago
Why? time_t is signed
4 comments

Neither C nor POSIX requires time_t to be signed.

The Open Group Base Specifications Issue 7, 2018 edition says that "time_t shall be an integer type". Issue 8, 2024 edition says "time_t shall be an integer type with a width of at least 64 bits".

C merely says that time_t is a "real type capable of representing times". A "real type", as C defines the term, can be either integer or floating-point. It doesn't specify how time_t represents times; for example, a conforming implementation could represent 2024-12-27 02:17:31 UTC as 0x20241227021731.

It's been suggested that time_t should be unsigned so a 32-bit integer can represent times after 2038 (at the cost of not being able to represent times before 1970). Fortunately this did not catch on, and with the current POSIX requiring 64 bits, it wouldn't make much sense.

But the relevant standards don't forbid an unsigned time_t.

Apparently both Pelles C for Windows and VAX/VMS use a 32-bit unsigned time_t.
From IEE 1003.1 (and TFA):

> If year < 1970 or the value is negative, the relationship is undefined.

In addition to being formally undefined (see sibling comment), APIs sometimes use negative time_t values to indicate error conditions and the like.
Probably because the Gregorian calendar didn't always exist. How do you map an int to a calendar that doesn't exist?