• (nodebb)

    Nonsense, it's only the end of the frist season of Futurama

  • TheCPUWizard (unregistered)

    23:59:59.9999999 UTC, December 31, 9999 in the Gregorian calendar, exactly one 100-nanosecond tick before 00:00:00 UTC, January 1, 10000.

  • (nodebb)

    I have to say that if we are doomed to have an End of Times, I really prefer that it be long after I'm dead. So at least today's code got that much right.

  • Scragar (unregistered)

    We ofter talk

    Typo? Pretty sure that should say "often"

  • Sauron (unregistered)

    I'm impressed that the author of that code takes into account contingencies like the End of Time. At least it's a thorough approach!

    That being said, it raises some rather deep metaphysical questions: how to test that the code behaves well in such a case before deploying it? Is it even possible to do so? Or to simulate accurately the destruction of the Earth for testing purpose? What budget would it take to test it? Are all software development processes fundamentally flawed because the End of Time is an untestable case?

  • Charles Shapiro (unregistered)

    The Real end times, as everyone knows, begin on 03:14:08 UTC on January19, 2038. All 32-bit Unix timestamps roll over to zero. Only 14 years away.

  • Confucius (unregistered)

    Pfft. Everyone knows the End of Time is either 9999-12-31 or 2999-12-31.

  • (nodebb)

    All TLS certificates have an expiration date on them, after which clients won't trust ever trust them. When we need to create a self-signed cert for whatever reason, we set the expiration date to be 1,000 years in the future from the current date. So those are all set to expire some time in the 31st century, but not all at the same time.

  • JanVP (unregistered)

    About Y2K: I love how programmers (a young profession at the time) thought their code might outlive them and added (the correct) leap year code for "00" (=not leap year). But, by doing that, made their code worse because the very first "00" the code would see (2000) was divisible by 400 and therefore an exception to the exception. Adding code for the latter only makes sense if said program will be in use for another 400 years - but we did it anyway, just to make it clear that we checked that library.

  • Abigail (unregistered)

    Well, sometime ago I wrote some code with the comment "This comparison may start failing after the first Tuesday in 2990". (Which it actually may do if the code still runs).

    I considered making a ticket for it, with a due date of 2990-01-04, but the ticket system didn't let me plan that long ahead.

  • Paul Tomblin (unregistered)

    In the 1980s, I worked in an ibm mainframe shop, and we stored a lot of stuff on 9 track reel to reel tapes (mag tape). Everytime you created a tape, you had to specify a new magtape, you gave it an expiration date. Tapes that were for archive and weren’t supposed to expire were given 990101. I wonder how busy the tape guys were erasing archive tapes on January first, 1999.

  • Andrew Klossner (unregistered)

    It's a genuine Microsoft limitation. From https://learn.microsoft.com/en-us/previous-versions/a442x3ye(v=vs.140) "_localtime64_s, which uses the __time64_t structure, allows dates to be expressed up through 23:59:59, December 31, 3000, coordinated universal time (UTC)"

  • Kelly Hrdina (unregistered)

    In GPS circles, we have two different instances of End of Time.

    GPS time is defined in a public specification, IS-GPS-200, as starting at midnight UTC between January 5 and 6 1980. It's made up of a "Week Count" and a "Time of Week". Some older systems used a 10-bit week count, so there was already a rollover even in August 1999 that caused some problems for the unprepared. A second happened in April 2019.

    Some more modern equipment uses a larger representation of the week count. For them, the End of Time will be 6 January 2137.

  • DB (unregistered)

    I have written this exact piece of code as an intern... in 2012(*). Boss-man said 'we need to stop times in the far past and future', but didn't give good values as to what 'definitely invalid' was. So I picked Dec-31st, 3000 and 'the day I wrote this code' as the two end points of valid time, so when the internal clocks were outside it, we'd push the date-time ranges to some valid-ish future point, so the DB time indices were unique to the span. (And then someone would have to clean it up)

    *Though, might just be a coincidence.

  • Oracles (unregistered)

    The real WTF is the expectation that people will be using non-ISO date formats in the year 3000.

  • Fizzlecist (unregistered)

    I love the confidence that the code will still be running in the year 3000, although if it was COBOL code I might just believe it

  • (nodebb)

    In the real world your date storage format will have some minimum and maximum value. Normally there is no out of band indication for date underflow or date overflow. Thus underflow gets represented as the earliest permitted date and overflow as the latest permitted date. Likewise, the in-band nature of date storage means you have no value for unknown.

    My current work. When did X happen? We have no record of X having been done but somebody is sitting there downstream of X and did mark their job as done. Clearly X did happen, but we will have no information as to when. Thus it's marked as occurring at the end of time--better to have it not show in date related queries at all than stamp it with the downstream time.

    The only way to get around an end of time concept is to have an out-of-band before/after/unknown/actual value--and good luck getting everyone to agree as to how to do it.

  • John (unregistered)

    I have used dates like that to detect typos but more recently check against "any future date"

  • Aussie Susan (unregistered)

    RE; Y2K - when I was working on the Y2K 'problem (while at a (then) big computer company), we had the concept of an 'event horizon'. In other words when will some aspect of the code need to go beyond 1/1/2000 (in either normal or US format!!!). For example, 1 30 year mortgage raised anytime after 1/1/1970 will hit the problem - that was that code's 'event horizon'. Susan

  • (nodebb)

    I'm worried that the successful dodging of Y2K problems (i.e. the lack of planes falling from the sky) means that no-one will get their PHB's to sign off on the required fixes to avoid Y2K38.

  • (nodebb)

    We're having so much fun with the bigger picture that nobody stopped to read the code.

    Start with what's probably a key-value map of strings. Then pull out one (probably stringly) value and.ToString() it. But with no culture so if it is some sort of DateTime object, we just went into unpredictable land. Then DateTime.Parse() that string using a particular culture. Ignore any exceptions, like for an out-of-range unparseable value. Then .ToString() the resulting Datetime into a particular format (US-centric of course) and compare that with a magic string value. Instead of using the built-in DateTime.MaxValue.

    So few lines. So many errors.

    Great. Just friggin' great. Sigh.

    FYI, ref Microsoft the built-in DateTime.MaxValue is

    The value of this constant is equivalent to 23:59:59.9999999 UTC, December 31, 9999 in the Gregorian calendar, exactly one 100-nanosecond tick before 00:00:00 UTC, January 1, 10000.

  • Manuel Hohmann (github)

    I wonder what actually comes after that "if" - what code will be run when time ends?

  • (nodebb)

    tempDate? dr? auCulture? Oh boy...

  • Tim (unregistered)

    Note the code is checking for == that specific date, not >=

    I suspect that date is used to indicate something specific in the code. Possibly (but not necessarily) in an environment that doesn't have a predefined concept of "max possible date value"

  • (nodebb) in reply to Scragar

    We ofter talk

    Typo? Pretty sure that should say "often"

    Nah, it's just Strine. "We ofter talk, they accepted the offer, we cracked open a tinnie and talked".

Leave a comment on “The End of Time”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article