SoylentNews is people
SoylentNews
Not one to let trivia pass unnoticed, the timing of this post has a mildly interesting significance.
Some of you may be old enough to recall the Y2K bug (or may have even helped in avoiding the predicted calamity). Thanks to an incredible effort, the world survived relatively unscathed.
So we're in the clear, now. Right?
Not quite. In the land of Unix timekeeping, there is another rollover bug coming up, when the number of seconds since the Unix Epoch (Jan 1, 1970) exceeds the space provided by a signed 32 bit number: 2147483647 (January 19, 2038 at 03:14:08 UTC). [See Wikipedia's Year 2038 problem entry for more details.]
The timing of this post marks our reaching 75% of that a milestone towards that rollover amount: 1,500,000,000 seconds since the Unix epoch which works out to 2017-07-14 02:40:00 UTC. (Queue Cue horns and fanfares.)
Besides taking note of a mildly interesting timestamp, I'd like to offer for discussion: Falsehoods programmers believe about time.
What memorable time (or date) bugs have you encountered?
I once worked at a company where the DBA (DataBase Analyst) insisted that all timestamps in the database be in Eastern Time. Yes, it would fluctuate when we entered/exited Daylight Saving Time. Even better, this was central database correlating inputs from PBXs (Private Branch Exchanges) across all four time zones in the US. No amount of discussion on my part could convince him otherwise. I finally documented the situation like crazy and left it to reality to provide the final persuasion. Unfortunately, a defect in the design of their hardware manifested at a very inopportune time, and the company ended up folding.
(Score: 2) by tangomargarine on Friday July 14 2017, @03:37PM (2 children)
One would hope that at some point in the next 19 years we'll universally be on 64-bit computers.
Isn't this a problem that can be solved right now by just upgrading it to a 64-bit int?
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by kaszz on Friday July 14 2017, @05:42PM
64-bit integer seconds pretty much solves it. Provided that you count seconds and not nanoseconds like say IBM do. The other catch is interfacing to other systems. Even if you don't collect time from them. If they fail because of timing issues they might deliver other bad data or not at all.
(Score: 1) by toddestan on Friday July 14 2017, @11:31PM
You may think 19 years is a really long time away, but it's not that uncommon to see stuff from the 90's still in use, which wouldn't be too different from something that exists right now still being used when 2038 rolls around.
You're right that using a 64-bit int solves the problem, but it breaks backwards compatibility with existing software that expects a 32-bit int. Some systems have decided to break compatibility, while others have decided to maintain it, at least for now. Luckily when going to 64-bit most systems decided to expand to 64-bit because everything had to be recompiled anyway, so a lot is limited to 32-bit stuff. But that doesn't mean there aren't other assumptions made somewhere that might break.