Email or username:

Password:

Forgot your password?
Top-level
HellPie

@0xabad1dea the real end of technology wasn't y2k, it won't be 2038, but it might be leap years

also i wonder if they fucked up with this, how do they handle japanese dates

7 comments
Delta Wye

@hellpie @0xabad1dea We had some industrial equipment that sort of shit itself when transitioning from 2019 to 2020.

It went from December 31st 2019 to January 1st 34210 or something batshit like that.

Bernd Herd

@DeltaWye @hellpie @0xabad1dea I've programmed code in 1993 that assumed that '31.12.19' means '31.12.2019' and '01.01.20' means '01.01.1920'. I'm still using that program and had to change the sourcecode in 2020.

Dan Neuman

@DeltaWye @hellpie @0xabad1dea Original programmer in 1970: "nobody will be alive in 2020..."

Clifton Royston

@DeltaWye @hellpie @0xabad1dea

Yes, this is how some developers "fixed" the Y2K bugs that were given them to fix.

Kick it down the road 20 years, and if anybody's still using the equipment it'll be somebody else's problem to fix.

Alexander The 1st

@hellpie @0xabad1dea Japanese date format is almost certainly something that they have a solution for-you *could* just indicate the difference in the U.I., but store the date format the same way internally.
That,and you can test it on any given day much easier.Leap years you have to check for specific years it's being set for (Generally) every four years, that sounds like the easy check...except for the exceptions when within 4 years it's not a leap year.
It's a harder version of DST checking...

Alexander The 1st

@hellpie @0xabad1dea ...which is to say that Spring Forward and Fall Back DST checks (And the related differences with regards to which countries and time zones switch on DST and when, and which direction.) is my bet on what is likely to be the next thing that trips until they can fix it after a hotfix of just manually changing the time.

Go Up