On a 32 bit machine, a long is 4 bytes, and it's still going to be 4 bytes even after glibc does their "time_t is now 64 bits" thing that's coming down the pipe eventually. longs aren't going to change.
So, when does this break? It turns out… 12 hours BEFORE everything else blows up. "DAY" is defined in the source as (24L * 3600L), so 86400 - the number of seconds in a day. It's taking half of that (so 43200 - 12 hours worth of seconds) and is adding it to the value it gets back from get_date. That makes it blow up 12 hours early.
2038-01-18 15:14:08Z is when that code will start returning negative numbers. That'll be fun and interesting.
Remember, the actual "end times" for signed 32 bit time_t is 12 hours later: 2038-01-19 03:14:08Z.
The lesson here is: if you take a time and do math on it and shove it into another data type, you'd better make sure it won't overflow one of those types that won't be extended between now and then.
Tonight's rabbit hole: time math and 32 bit longs
from Writing - rachelbythebay
