Stories
Slash Boxes
Comments

SoylentNews is people

posted by n1 on Friday July 14 2017, @02:40AM   Printer-friendly
from the I'll-second-that! dept.

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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by fishybell on Friday July 14 2017, @03:41AM (2 children)

    by fishybell (3156) on Friday July 14 2017, @03:41AM (#538957)

    Gaaaaah. The addresses thing messes me up all the time.

    I live in Utah, where almost every address is a grid location (ex. 500 N 300 E), not a number plus street. (ex. 500 Main).

    Just today I couldn't pay a medical bill online because they wanted my street number, plus the street name rather than just the whole thing together.

    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by kaszz on Friday July 14 2017, @04:13AM

    by kaszz (4211) on Friday July 14 2017, @04:13AM (#538965) Journal

    Street: 300E
    Number: 500N ? ;-)

    Or just make one up? "500 Gigajoules, Utah".
    Oh it doesn't exist? must be wrong on your computer. Hit it hard! If it doesn't work it might be that the Coriolis effect is upclocking your mains frequency so your Ze-Pe-You can't think fast enough!

  • (Score: 2) by VLM on Friday July 14 2017, @02:06PM

    by VLM (445) on Friday July 14 2017, @02:06PM (#539114)

    Its the modern version of refusing to do business with "New Mexico" because we don't do international.

    I recall once seeing an address field that refused to accept no apartment number, you had to enter 0000 to be accepted, admittedly a very long time ago.

    A surprising common mistake is refusal to accept city names containing spaces.

    Another good example is zip codes, it seems roughly 50/50 if zip+4 will be mandatory or forbidden

    I would guess less than 1% of programmers working with addresses know about https://www.usps.com/nationalpremieraccounts/manageprocessandaddress.htm [usps.com]