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: 2) by krishnoid on Friday July 14 2017, @03:17AM (4 children)

    by krishnoid (1156) on Friday July 14 2017, @03:17AM (#538954)

    There are also lists of falsehoods that programmers believe about addresses [mjt.me.uk], names [kalzumeus.com], and other descriptors. I'd like to have three case studies/examples of each falsehood to refer to when decision- and schedule-makers inevitably choose to assert that these problems don't exist, don't come up in the real world, or that their behavior can be left undefined.

    We could then determine which of these issues to make a conscious decision to gloss over. Or at the least, introduce a little padding into your typical project schedule while stakeholders bikeshed the issue to death.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (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.

    • (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) Subscriber Badge 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]

  • (Score: 1, Interesting) by Anonymous Coward on Friday July 14 2017, @07:40AM

    by Anonymous Coward on Friday July 14 2017, @07:40AM (#539007)
    Most of the name myths are true. It's just that people try to substitute in other concepts, call them a "name" when really they aren't, and then claim that they aren't handled correctly. Yes that is the NTSF, I take no shame in that.

    If you don't have something which conforms to the simplified concept of a name, then you don't have a name. If your culture doesn't have something which conforms to the simplified concept of a name, then your culture doesn't have "names". Sucks to be you. Go invent your own internet to handle the contrivances that you still cling to despite their illogic.

    You know what happened when Swedish census takers asked their Finnish underlings for their surnames - "what's a surname?". There was no such concept. But the Swedes demanded surnames. So the Finns just invented them (most being topographic/geographic/otherwise-place-related). Tada - henceforth in every subsequent census, and elsewhere in life, everyone had a surname. Problem solved (from the perpective of the Swedes). If your "name" isn't useful enough, get a more useful one, stop going "wah, wah, wah, our naming scheme is special, make exceptions for us, wah, wah, wah".