I don't think I was at the only company doing this. Few people seem to care about issues that will happen after their retirement. Expect lots of industrial stuff to work just a bit worse around 2038 (and 2036, PIC microcontrollers fail a bit sooner)
Almost all things that have a timestamp leave you in no doubt which 136-year period they were taken in. For those, 32 bits is plenty.
Existing code that deals with 32-bit timestamps almost universally assumes that (time_t)0 is 1970-01-01 00:00:00 UTC. Updating that code to guess a different epoch would be more work (with more inevitable bugs) than keeping a fixed epoch and using 64 bits.
It's already 64 bits (and signed) on a lot of systems.
Think of an odometer for a car with 999999 as its max number. 999,999 is equivalent to -1. So 500 + 999999 == 499 on the odometer.
A 32-bit register is simply a binary odometer, so the above concept happens with bits.
In "signed int", we print the number "999999" as "-1". With "unsigned int", we print the number "999999" as "999999". They are one-and-the-same. The only difference is your print() function.
-----
Multiplication and division change however. Your compiler tracks signed/unsigned status for idiv vs div, or mul vs imul instructions.
--------
With that being said: I think 64-bits is fine. Most computers these days are 64-bits, and those 4-extra bytes aren't very costly. Standard compression algorithms, like GZip, do a good job of finding those redundant bits and shrinking things down.
Except signed overflow invoking Undefined Behaviour in any C compiler, whereas unsigned overflow does not.
This invokes undefined behaviour:
foo(int x) {
return x + 1 > x;
}IIUC, GP's foo() would likely be optimized to { return true; }, and so would similar timestamp overflow checks.
Given this thread of subargument, making the difference between 32-bit unsigned numbers is MORE DEFINED than using signed integers.
-------
IE: If your code was correct with "int timestamp", it will be more correct with "unsigned int timestamp".
In any case, "int" or "unsigned int" based timestamp manipulation wouldn't be like the code you suggested, but instead "int difference = x - y".
In the signed integer case, "difference" is (conceptually) negative, while in the unsigned integer case, "difference" is guaranteed to have overflow. Both cases are conceptually correct with regards to the difference of timestamps.
To get meaningful results may require some care, but the languages provide everything needed to exercise such care.
> Except signed overflow invoking Undefined Behaviour in any C compiler, whereas unsigned overflow does not.
We aren't talking about unsigned integer types. We're talking about the behaviour of signed integer types.
---
Openldap got hit by the billennium bug. I remember because we told our Noc to keep an eye open (Sunday afternoon where we were) and we started getting alerts that all LDAP replication was broken.
https://www.openldap.org/lists/openldap-bugs/200109/msg00052...
---
Link to 1400000000 thread:
http://www.davideous.com/imap-maildir/#updates
The sort function couldn't handle the rollover so when we came in that day all our mailboxes had their email sorted in the wrong order, and it couldn't be fixed without the listed patch.