3 ms·
Why? time_t is signed
by usrnm 2y ago
Why? time_t is signed
- growse 2y agoFrom IEE 1003.1 (and TFA): > If year < 1970 or the value is negative, the relationship is undefined.
- layer8 2y agoIn addition to being formally undefined (see sibling comment), APIs sometimes use negative time_t values to indicate error conditions and the like.
- 8n4vidtmkvmk 2y agoProbably because the Gregorian calendar didn't always exist. How do you map an int to a calendar that doesn't exist?
- wahern 2y agohttps://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar
- _kst_ 2y agoNeither 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.
- _kst_ 2y agoApparently both Pelles C for Windows and VAX/VMS use a 32-bit unsigned time_t.