• DQ (unregistered)

    Damn, I retire june 2038. Just a little to late to say 'Not my problem'

  • TheCPUWizard (unregistered)

    One "quick fix" for the 2-digit-year problem was to make assumptions... it is the late 1990's - we have historical data going back XXX years - so we want things "in the future to be 20xx but things in the past to be 19xx.... Where is the dividing line.... Well - 20 or 30 both seemed to be common choices [strangely, to me, 25 was less common than either of those].... so year "29" is 2029, but year "30" was back in 1930...

    [Note: These choices are the very embodiment of "technical debt" as it is truly defined, The cost for the "quick fix" was smaller in the short term, but it was well known and acknowledged that it would cost much more to fix i the future - but the people figured they would be retired, or at least with a different firm by then]

  • (nodebb)

    for( year=2000; year < 2000000000; year++) {...}

    there you go. made the code work until the heat-death of the universe. oh... wait...

  • Rob (unregistered)

    This looks like c# yet that did not exist in 2000....

  • Dave (unregistered)

    Why would 3 different _D_ay _W_eek _M_onth lists each need to get their own year value? Seems like some ineffective and redundant calendar controls on that page.

  • David Jackson (unregistered)

    As many people have said before, the real problem with year selectors is how tedious it gets scrolling down to your year of birth.

  • (nodebb) in reply to TheCPUWizard

    Note: These choices are the very embodiment of "technical debt" as it is truly defined, The cost for the "quick fix" was smaller in the short term, but it was well known and acknowledged that it would cost much more to fix i the future - but the people figured they would be retired, or at least with a different firm by then

    Don't forget the other possibility for doing it like that: the dates came from an embedded system with a built-in clock that only held two digits, so the software on the receiving machine had no choice but to engage in the "windowing" approach you described. (i.e. the technical debt was in the hardware chosen, not the approach to storage in software.) But when I did that in the early 90s, I assumed that the hardware (battery-powered gas flow correctors) would be in service for a long time, but equally that the PC software that extracted the data would not have to deal with dates before 1990, so the windowing was 90-99 ==> 1990-1999 and 00-89 ==> 2000-2089.

  • (nodebb) in reply to Rob

    I "wrote" my first code in C# on a conference in December 1999 :-) I think the regular BETA started before 2002 but I can't remember exactly.

    But yeah, this code actually handled some historic values in a weird way.

  • (nodebb)

    In less than three months I need to go and add in another 10 year's worth of weeks to one business unit's calendar in an application we use, and then go and update everything to run until the end of the new last period. (Because open end dates aren't a thing the application allows.) And document it, so in just under 10 years' time we can do it again for both BUs, if we're not off the platform by then. It's quite an involved process because everything has to be done in a strict order - child objects have to have a date range contained within their parent object's date range.

    [When I created the first BU, I set it up with 20 years' worth of periods. But then the users had a bunch of useless error messages pop up because there were more periods than the application liked, so I only set the second BU up with 10 years' worth. They did eventually fix the error messages, at least.]

    Also annoying: if you set your calendar to be Weekly, then there must be exactly 52 periods defined in every year. So you have a choice between "every now and then you have a 14-day-long 'week' and you can only do one payment run in that time", or "I know our financial years are supposed to be July to June, but this one is mid-May to mid-April". (In our case, one BU does it the first way and one does it the second way.)

    It's possible some of this has improved since I last looked at it, but I'm not hopeful.

  • Erwin (unregistered) in reply to David Jackson

    And then there is this website where I had to select my birth date in a date picker. The date picker showed a month of dates at a time, without keyboard input to select the year. They already knew my age category (with about a decade of birth years per category) so they could have started started the date picker in the right decade. Instead, they started the date picker at the current day. Selecting my birth date required over 700 clicks on the "previous month" button.

  • Officer Johnny Holzkopf (unregistered) in reply to Dave

    2024-03-28: day = 88/2024, week = 12/2024, month = 3/2024. All need to have their own year number, because... erm... management said so! Now switch your brain off and get back to work, worthless underlings!

  • Fordom Greeman (unregistered)

    I had a similar problem at work, a batch job would store processed files in directories separated by year (with no checks of course), it would fail at the first week of january every year, and every year we would scratch our head and 5 minutes later "oh, its THAT bug again, I'll just create the current year dir" then I had enough of it and solved the problem once and for all with a single line of bash code: "mkdir 20{24..99}"

  • (nodebb)

    So.....If this year is 2024, why can you pick year 2030 at all?

  • markm (unregistered) in reply to David Jackson

    Ah yes, one of the worst things I've seen in interface design: the long scroll down for something you could have typed with 4 keystrokes. For example, when it asks for my birthdate, if I'm over 4 years old typing is faster. But instead of allowing typing, they give me a drop-down list, which I have to scroll all the way back from 2024 to 1953.

  • markm (unregistered) in reply to davethepirate

    "If this year is 2024, why can you pick year 2030 at all?" Because in some applications, you need to enter a future year, and in some it may be past, present, or future. The expiration date on my drivers license is probably in the future, but if I hadn't renewed the license last year it would now be in the past.

Leave a comment on “Never Retire”

Log In or post as a guest

Replying to comment #:

« Return to Article