I find this absolutely hilarious.
Honestly working with local date and time is a pain in the arse; if everything was kept at UTC and only displayed as Local time, it would be so much easier. Daylight savings makes everything worse!
Even if you lose access to your time server you can keep fairly accurate time by counting with your local clock from your last registered timestamp; the local clock should be able to keep to a few ms/day accuracy.
I can understand Y2K bugs where it only happens once in 1000 years, but how does this happen when leap years are so common?
It’s not like everyone programs a calendar from scratch, I’m trying to understand how they could have screwed this up.
I’m going to watch this again.
Haha that’s a pretty entertaining watch (pun intended).
I still want details on how a leap day can take down a petrol station! My money is on time-based encryption but really it’s anyone’s guess. It just seems like things should still work even if (somehow!) the date is set wrong.
It could be even simpler.
If they couldn’t put the date as 29th Feb yesterday most card payment machines wouldn’t allow them to connect. Especially if it was “March 1st”
Much like the reasons for the “leap second smear” Tom mentions at the end of that video. Banks really care about continuity and knowing the order of events.
But what series of events could possibly lead to there being no February 29? As Tom mentions in the video, you don’t do this stuff yourself, there’s no reason to build that yourself.
My new guess is they had the year set wrong and no one noticed until now.
Poor Tom.
