21 comments

[ 2.7 ms ] story [ 62.3 ms ] thread
It should be sufficient if we hot-patch the end date to 2030 - we'll surely have updated or replaced those systems until then.

I'm curious what part of the system even required specifically coding an end date, and not just sanity checks relative to the current date.

> I'm curious what part of the system even required specifically coding an end date, and not just sanity checks relative to the current date.

It's working as designed... liability and support was shifted to the owners (cities) prior to the event.

I’m sure that’s what they also thought in 1981 when storing only 2 digits of the year and we all know how that turned out.
I honestly am using 2 digit years again because I know I'm not going to care in 2100.
Creating job security for the developers of 2098, I see :)
I have no experience with parking meters, but surprising that software updates need to be done at the site/hardware (as opposed to, say, online or "over the air" or updates).
Easier to secure and administer I would guess. More and more orgs are realizing that IOT admin is a bigger burden than a liberator to those who are responsible for upkeep.
If we can judge the vendor's competence from the problem reported here, then if they had made them updatable wirelessly, they would likely be easily hacked.
> Y2K20

It’s 2020. Why use a cryptic abbreviation with more characters? If they want to use the SI “k” prefix shouldn’t it be Y2.02k?

Perhaps it's a reference to a standard for labeling electronic components. For instance a resistor with 3300 Ohms will be labeled "3k3" on a diagram. It eliminates the decimal point, which might be hard to read or even fall off if it's printed on a tiny component.
That would be "2K02". It's actually a (bad) abbreviation of "two[2] thousand[K] twenty[20]".
This is so funny I just had a similar bug yesterday and named it our y2k20 bug, just a path name change that someone forgot to map correctly
One of a number of errors that are showing up. My favorite are the websites that regex the '20' out of the year to get just the decade, "Whoops!"

In many ways I'm glad we didn't bother to fix the bugs this year like we did for the 1999 - 2000 transition. Way too many people think that Y2K was just some big 'scare tactic' and nothing ever happened. It is sad that operations is always like that, you work your arse off things operate smoothly and the unknowing just say "I don't see what the big deal was all about."

Reliability work is unfortunately under-observed and under-valued... until its absence triggers an incident.
Who wants to bet that is not a numeric bug, but a certificate expiry?
We had to do an emergency patch to the config of a well-known data analytics platform, because their regex to identify/extract 2 digit years did not cater for anything beyond 2019... We dodged that bullet, but shows a lack of foresight by said company. Lucky we don't have much data that has 2 digit year dates.
It only effects card payments. Cash still works. It appears the CA certs may have expired and a secure connection to the credit card server can't be established.

Easy fix but you do need to update your machines from time to time...

My Android phone started glitching and freezing just after the new year. I'm assuming it's a hardware failure, but I wondered if it were a year 2020 bug (or a virus).