• (nodebb)

    At least it's in a language (looks like VB) that's ASCII-only, so mod is a possibility. Imagine if it was C or C++ on a zSystem, where 'J' =='I'+8.

    https://en.wikipedia.org/wiki/EBCDIC

  • Kitihounel (unregistered)

    I guess doing ((year % 2000) % 26) + 65 to get the ascii code for the letter assigned to the year was too hard...

  • LCrawford (unregistered)

    In the year 2026, if Jose's company is still alive - they learn that all reports have to be updated so that 'A' product becomes newer than 'Z' and records from 2020 have to be purged to prevent old data showing as new.

    In the year 2525, if Jose's company is still alive - the code will have rotated 20 times and will receive an F for the year.

  • RLB (unregistered) in reply to Steve_The_Cynic

    Imagine if it was C or C++ on a zSystem, where 'J' =='I'+8.

    char yearletter = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"[(year - 2000) % 26];

    HTH; HAND.

  • (nodebb) in reply to RLB

    Yup, that works, but somehow I imagine that most of the creators(1) of code samples for this site wouldn't build it that way.

    (1) The people who originally wrote the code that gets submitted, not the submitters.

  • (nodebb) in reply to Kitihounel

    I guess doing ((year % 2000) % 26) + 65 to get the ascii code for the letter assigned to the year was too hard...

    Too hard or not, it's wrong, except that you won't notice it until someone needs to port the code to a zSystem, the spiritual inheritor of the IBM System/360 family, which doesn't use ASCII.

  • van Dartel (unregistered) in reply to RLB

    As the core of a solution that implementation sketch makes perfect sense. Two pitfalls though:

    1. Modulo can give negative results (year = 1999 would correspond to [-1])
    2. Array indexing is more robust than string indexing (consider for example an extension of A, B, … by α, β, … in UTF, where the additional sequence requires more than one byte per character)
  • ooOOooGa (unregistered)

    For compatibility with non-ascii systems you could create an explicit map or enum that maps integers 0 .. 25 to 'A' .. 'Z', then ((year - 2000) % 26) would give you the appropriate lookup integer. Very similar to what RLB mentioned above.

    Which still doesn't fix the problem of having to remember in 2026 to either purge all of the 2020 information or add mapping and range to the system for year values above 2025.

  • (nodebb)

    How is that for an end of the world prediction.

  • Tom (unregistered)

    If this code runs on December 31th at 23:59:59, an interesting bug could happen... The year could change between calls to DateTime.Today.Year.

  • Carl Witthoft (google)

    In the year 2525 If man is still alive If woman can survive

    ... software bugs will still plague us all

  • James (unregistered)

    I am familiar with a system that uses a similar Y2K workaround, except they used the letter to represent the decade (e.g., A1 = 2001, B2 = 2012) so we still have around 230 years before we need to worry about what happens after Z.

  • Brian Boorman (google) in reply to Carl Witthoft

    +1 for the Zager & Evans reference. I remember that from the mid-70's when I was in elementary school.

  • Some Ed (unregistered) in reply to Steve_The_Cynic

    Not using ASCII is not a problem. There's plenty of viable character encodings besides that, like UTF-8.

    EBCDIC may not be one of those. I understand that there's a lot of history there, but that felt to me like a major WTF from when I first heard of it, and I don't recall having heard anything since that makes it better.

    It's my understanding that most of the world has moved to unicode. I'm in the US, and even our systems are being moved to using UTF-8 rather than ASCII. I'm not sure what reason people have for continuing to use a broken by design character encoding, but it feels to me like it's only going to get more painful over time. Transitioning from one character set to another is possible, you just need to either manage to do it more or less all in one migration, or you need to identify all strings/files by their charset, so you can deal with having a mix.

  • 516052 (unregistered) in reply to Some Ed

    I would imagine it's the same reason why some people insist on using a broken by design system of weights and measures.

  • jay (unregistered) in reply to 516052

    "I would imagine it's the same reason why some people insist on using a broken by design system of weights and measures."

    There are two kinds of countries in the world: (a) those that use the metric system; and (b) those that have put a man on the Moon.

  • jay (unregistered)

    It's good for 26 years. 26 years from now, I'll have almost certainly moved to another job, so it will be someone else's problem. Why should I worry about it?

  • DJ Dizzy Spudplucker (unregistered)

    Back in 1994, we implemented a version stamp system using letters for each quarter of a year A...Z and three digits for the day of the quarter (which even allowed for 400 days in a year!). Yes, we knew it would break after six years, but we also knew we wouldn't be working there more than another two years......

  • 516052 (unregistered) in reply to jay

    You mean those that wasted money on pointless prestige projects in space and those that used that money to give their people living wages, consumer protection, free healthcare and education and other actual benifits. Right?

Leave a comment on “We All Expire”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article