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
- Dependencies (coupling) is an important concern to address, but it&...from kbouck
- By replacing integration tests with unit tests, we're losing al...from Computer Things
- I propose that there is one problem chief among them, an impetus fo...from George Hosu
- When software -- or idea-ware for that matter -- fails to be access...from gist.github.com
- Any software is considered free software so long as it upholds the ...from writefreesoftware.org
- Nathan's four Laws of Software: 1. **Software is a gas** ...from Jeff Atwood
- > Any sufficiently complicated [C](https://en.wikipedia.org/wiki...from From Wikipedia, the free
- Ad-hoc validation leads to a phenomenon that the [language-theoreti...from Alexis King