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 bradley13 on Friday July 14 2017, @09:54AM (2 children)
Date formats. Not only where users can enter them, that's bad enough, but also in databases and programs, sometimes different, sometimes leading to exciting and hard-to-diagnose problems. Times (and dates) with and without time zones, so it matches expectations for several months, and suddenly doesn't anymore.
Dates and times are a source of nightmares when you have to interoperate with other pieces of software, and you cannot find out what assumptions they have made...
Everyone is somebody else's weirdo.
(Score: 0) by Anonymous Coward on Friday July 14 2017, @04:24PM (1 child)
I refuse to use any datetime data types in SQL for most projects. For most business applications, storing the number of seconds since the Unix epoch (Unix time) and relying on a library like Joda Time to represent the instant as something an end user can read (local time) just saves so many headaches.
(I usually also set up stored procedures/functions/whatever's most appropriate for the RDBMS being used to convert these to the RDBMS' datetime type, but converting to local time in my view is an artifact of the presentation layer [view in MVC].)
Going from int to bigint easily solves the Y2.038k problem this might otherwise present, and if bigint isn't big enough, I don't know, use a decimal type. If that's not big enough, well, I did say business applications. I don't see why it couldn't scale by adding on bit after bit until the type is wide enough. Maybe some kind of vardecimal, I don't know. I haven't found a situation this basic approach won't work for, even if we need to decide we're storing milliseconds or whatever instead of seconds.
If you ever think you don't need time zones, you're wrong.
(Score: 2) by kaszz on Friday July 14 2017, @05:48PM
When would you say the builtin SQL dates will fail? because some people are likely to use them..
What is the approach to handle stuff like leap seconds? because a day isn't always 86400 seconds long.