> it also removes the ability to represent any date/time prior to 00:00:00 UTC on 1 January 1970 using 32-bit time_t
Yes, of course. This is probably not the main use of negative values with signed time_t, though -- which is just representing the result of subtraction when the operand happened before the subtrahend.
> Having all existing stored date/times that are currently prior to the epoch suddenly become dates post 2038 is also not a good scenario.
In practice, there are ~zero of these on systems with 32-bit time_t and a challenging migration path as we approach 2038.
> Yes, of course. This is probably not the main use of negative values with signed time_t, though -- which is just representing the result of subtraction when the operand happened before the subtrahend.
This is definitely a bigger concern, yes. One has to be very careful with subtraction of timestamps. But to be fair one already had to be very careful before because POSIX doesn't say what the size or signedness of `time_t` is to begin with.
Indeed, in POSIX `time_t` can even be `float` or `double`[0]!
time_t and clock_t shall be integer or real-floating types.
Though on all Unix, BSD, Linux, and any Unix-like systems thankfully `time_t` is always integral. It's really only size and signedness that one has to be careful with.
Thus one should always subtract only the smaller value from the larger, and cast the result to a signed integer. And one has to be careful with overflow. Fortunately `difftime()` exists in POSIX. And there's a reason that `difftime()` returns a `double`: to avoid having the caller have to deal with overflows.
Basically working safely with `time_t` arithmetic is a real PITA.
> Though on all Unix, BSD, Linux, and any Unix-like systems thankfully `time_t` is always integral. It's really only size and signedness that one has to be careful with.
Thus one should always subtract only the smaller value from the larger, and cast the result to a signed integer. And one has to be careful with overflow. Fortunately `difftime()` exists in POSIX. And there's a reason that `difftime()` returns a `double`: to avoid having the caller have to deal with overflows.
> Basically working safely with `time_t` arithmetic is a real PITA.
Yes, I know that was older POSIX. But we're talking about old code, the unstated context is portability over a long period of time, and I wanted to make a point :)
So use `difftime()`, don't assume signedness or size, but do assume that it's an integral type.
Yes, of course. This is probably not the main use of negative values with signed time_t, though -- which is just representing the result of subtraction when the operand happened before the subtrahend.
> Having all existing stored date/times that are currently prior to the epoch suddenly become dates post 2038 is also not a good scenario.
In practice, there are ~zero of these on systems with 32-bit time_t and a challenging migration path as we approach 2038.