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, Interesting) by John Bresnahan on Friday July 14 2017, @12:52PM
I worked on two major systems for Fortune 100 companies that had to be turned off during Daylight Saving Time changes, since the systems used local time, rather than GMT or epoch time. The spring shutdown only had to last a few minutes, but every fall the systems had to be shut down for just over an hour to make sure the system didn't see the "same" time twice in one day.
The other major problem I saw was when porting a legacy system to run in a virtual machine. The legacy system had been the master time server for a group of machines, and it was decided to keep that functionality on the legacy system. Unfortunately, the host computer which ran the virtual machine containing the time server used that time server to set its own clock, so any time the clock was adjusted, it would cause a feedback loop between the host and virtual machines (that is, the virtual machine would tell the host to change the time, which would cause the virtual machine's notion of the current time to change, which the vm would then treat as another time change, repeating the process).