• Little Bobby Tables (unregistered)

    Fri.

  • MiserableOldGit (unregistered)

    How much do you want to bet that the schmuck who wrote this was told "just do something quick and dirty,the new system is rolling out in a few months"?

  • 🤷 (unregistered)

    Yes. Why use perfectly fine, and well tested, date libraries when you can just write your own WTFy code? Where would be the fun in that?

  • (nodebb)

    If this was done in the 2000s, then the software laster longer than most of the 1980-199x software that caused the Y2K mess in the first place...

  • Dave (unregistered)

    It's a problem just 1% of the time. Not worth fixing.

  • Lost (unregistered)

    Just change it to:

    year = year.replace('20', '', 1)

    So it will only replace the first occurence.

  • (nodebb)

    Duh! Use regular expressions, obviously: replace 20(\d\d) with $1

  • The Mole (unregistered)

    Of course just doing a substr would have been simpler, more efficient and not have broken (until 10001AD)

  • Earth's Mellow Monk (unregistered) in reply to The Mole

    Substrings are the answer! year=year[-2:]

  • Simon Clarkstone (unregistered)

    Clearly a competent programmer would have connected to an SQL server and used the MOD() function there. (Environments like Java and .NET don't have a MOD() function and are therefore inferior.)

  • Wheresthespamohthereitis (unregistered)

    Up here in Norwaystan, people who are 105 this year have had their parents (!) called in to parent-teacher meetings in preparations for their first school year. Did they learn nothing from Y2K?

  • (nodebb)

    year = timezone.now().year % 2000;

    nuf said...

  • JimJ (unregistered) in reply to LordOfThePigs

    And this will misteriously stop working in 2100th.

  • TruePony (unregistered)

    Once the calendar year rollover bugs are through, it will just be time for fiscal year rollover bugs...

  • P. Wolff (unregistered) in reply to Simon Clarkstone

    Right. Who in their clear mind would think a percent sign could be used for anything but for "percent", especially in an enterprisey environment?

    And while we're at it: we must make sure we access a server which is available. If the first one fails, load a list with possible sources, and search every single one of them in turn, and let it evaluate its MOD() function.

  • P. Wolff (unregistered) in reply to Simon Clarkstone

    Oh, and .NET DOES have a MOD operator. Just not in the most used language C#, but in the clearly superior VB.NET. After all, it uses more human readable words, so it must be better.

  • P. Wolff (unregistered) in reply to MiserableOldGit

    "In a few months"? That lucky fellow! Usually, it's more like "next week" or "tomorrow".

  • Kleyguerth (github) in reply to P. Wolff

    And in some not-so-rare cases, "today".

  • King (unregistered)

    If this is the only problem with a system that only has 2 digits for year, then the system must be a true masterpiece created by a true genious.

  • Duston (unregistered)

    Oh come now, clearly everyone knows the answer to this problem is a switch/case statement.

  • ooOOooGa (unregistered) in reply to Kleyguerth

    The sales department promised a delivery date that was three days ago. Get to work.

  • Simon Clarkstone (unregistered) in reply to P. Wolff

    It still doesn't accept the correct syntax of MOD(x, y) though. Damned modern languages.

  • RetekBacsi (unregistered)

    "oh, I know it's a hack, but it's too late and I'll have 19 years to fix it. Probably will be done properly by next week..."

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    Oh that was a good one. This is the kind of black hole in thinking that goes on in the mind of your typical stringly-math idiot. I actually laughed out loud.

  • K (unregistered)

    Fortran uses % as field access operator.

  • kurkosdr (unregistered)

    We will face similar issues from now on every new decade: For many systems, the Y2K bug was "solved" not by making the 'year' field 4 digits long but by introducing the concept of "windowing", where (for example) any 2-digit years less than '20 are considered to be in the 2000s and any 2-digit years bigger or equal than '20 are considered to be in the 1900s.

    Similar problems will occur in 2030, 2040, 2050, 2060 and 2070.

  • kurkosdr (unregistered)

    We will face similar issues from now on every new decade: For many systems, the Y2K bug was "solved" not by making the 'year' field 4 digits long but by introducing the concept of "windowing", where (for example) any 2-digit years less than '20 are considered to be in the 2000s and any 2-digit years bigger or equal than '20 are considered to be in the 1900s.

    Similar problems will occur in 2030, 2040, 2050, 2060 and 2070.

  • ガ_ガ (unregistered) in reply to LordOfThePigs

    Why "timezone.now().year % 2000;"?!?

    If you want 2 digits, it's %100.

  • James (unregistered)

    Is it time to stop congratulating everyone on their efforts with Y2K?

  • Y2K (unregistered)

    I worked on a system in 1999 that stored years as single digits. It previously stored them as 2 digits but someone decided to repurpose the first digit as a status code instead of adding a field to the table. Thus our Y2K remediation more comical than most.

  • Who isn't a robot these days? (unregistered) in reply to P. Wolff

    Just be sure to build a table with all of the years 1900 to 2100 and their allowable two digit version. Problem solved.

  • (nodebb) in reply to MiserableOldGit

    I'm glad I learned through my own mistakes to never put a temporary system in place while working on a permanent one.

    Pretty sure one of the "temporary" solutions I made is still running a website backend 22 years after I wrote it.

  • Fnord (unregistered) in reply to Simon Clarkstone

    Right, "%" just won't do. Needs to have function semantics.

  • shcode (unregistered)

    brilliant. why take the last two digits, when you want to get the last two digits, when instead you can remove an arbitrary string from everywhere in the input?

    brilliant.

  • Anonymoustache (unregistered)

    I assume that it will be a major operation fraught with borkage if you try to change the year field from two digits to four digits.

  • Foo AKA Fooo (unregistered) in reply to P. Wolff

    "Who in their clear mind would think a percent sign could be used for anything but for "percent", especially in an enterprisey environment?"

    But of course, the percent sign means "percent". Let's try it:

    25% 4 == 1

    50% 4 == 2

    75% 20 == 15

    etc.

  • P. Wolff (unregistered) in reply to powerlord

    I'm glad I learned through my own mistakes to never put a temporary system in place while working on a permanent one.

    Pretty sure one of the "temporary" solutions I made is still running a website backend 22 years after I wrote it.

    Temporary systems are longer-lived than permanent ones. E. g. the Federal Republic of Germany was constituted as a temporary solution until Germany's reunification, and the German Democratic Republic as a permanent one (as a part of the ever-lasting communist block). And which one of them survived to this day?

  • RLB (unregistered) in reply to kurkosdr

    For many systems, the Y2K bug was "solved" not by making the 'year' field 4 digits long but by introducing the concept of "windowing", Windowing isn't in place because databases don't have four-digit years. Even in 1993, most - hell, even in 1983, many - databases did have four-year dates. The ones I worked with certainly did. No, the problem was user laziness, and that problem persists. Windowing doesn't exist because I can't store four digits, but because my users don't want to enter four digits. Still don't. MariaDB clearly can store dates, but last week I had to shift a window a couple of decades because one of our users wants to enter 010120 and have it interpreted as 01-01-2020.

  • Дмитрий (unregistered)

    Good news is that this bug will go away on the next new year. No need to fix it, it will fix itself

  • markm (unregistered) in reply to RLB

    If you must window, make the window relative to the current year.

    And manipulating numeric data - which dates are - as strings is just plain stupid.

  • Another Anon (unregistered) in reply to RLB

    Work with legacy systems that do both 2-digit and 4-digit years. Not sure what the trigger is for 2-digit logic, but it causes severe problems. We have a T.S.R. program that lets you configure the roll-over year; so if it's set to "15", then it goes 2014, 2015, 1916, and on and on. The legacy system is launched by a lot of different people, so we have to update the BAT files to change the call to the T.S.R., network-wide. Fun times.

    Another beauty is a web-app that was contracted out. End result from user entry is data with dates like 01/19/0020.

  • Year master (unregistered)

    The code is perfect. Will fix itself after a year. I don't see a need to spend time fixing it. Just mark it as won't fix.

  • anonymous (unregistered)

    If I was going to solve this by "mangling a string" I would use a substring operation (take the last two characters/remove the first two characters), not by doing whatever nonsense that was.

  • Neveralull (unregistered) in reply to powerlord

    Want to have a laugh? Search an existing large code base at the company you work for the following strings, which might appear in code comments: “Temporary” “To fix, or “to be fixed,” or just “fix.” “Kludge” ”Hack”

  • Game Developer (unregistered)

    TRWTF is using string replacement instead of substrings - seriously, just remove first two characters from the year and it will work always, until we get to the year 10000, at which point no one will care.

Leave a comment on “A Short Year”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article