It's that most wonderful time of the year when tech cannot handle the date
- Reference: 1709220609
- News link: https://www.theregister.co.uk/2024/02/29/fuel_pump_leap_year_bug/
- Source link:
This kludge prevents our seasons from drifting out of whack, but it presents a problem for computers and software, which have to be programmed to account for the extra day to avoid error conditions and incorrect data.
We are all using a computer of one sort or another to read this and hopefully nothing has caught fire, yet every leap year, something somewhere falls over hard.
[1]
In New Zealand, which has a head start on most of the world, it was payment systems at fuel pumps that have just staggered back to their feet after a nationwide outage lasting more than ten hours.
[2]
[3]
Allied Petroleum, Gull, Z, Waitomo, BP and more petrol providers were affected, which meant customers were unable to use debit and credit cards to pay for fuel.
Many locations closed their pumps for the duration, though in-house solutions like Waitomo's app worked just fine, presumably because they are professionally coded to deal with February 29 appropriately.
[4]
Unlike Invenco point-of-sale software encompassing fuel pump terminals.
Gull spokesperson Julien Leys said companies using Invenco terminals were suffering a leap year bug. "We have been liaising with our provider and understand they are working as quickly as possible to fix the issue," he told the [5]The New Zealand Herald , adding that February 29 is "just one of those things that caused payment software to have a glitch."
"Just one of those things" if the software isn't calibrated for the event, which to us is highly suggestive of human error. This is why developers use tried-and-tested libraries that have been around for decades, and don't typically dare to touch anything concerning calendar and time logic themselves lest they be fast-tracked to insanity.
[6]
John Scott, CEO of Auckland-founded Invenco, confirmed the leap year glitch and said that the fix had been rolled out to the network, allowing fuel pump payments to resume.
The Register asked Invenco to detail the nature of the error and how it was fixed. The article will be updated should the company respond.
[7]Curious tale of broken VPNs, the Year 2038, and certs that expired 100 years ago
[8]The 'nothing-happened' Y2K bug – how the IT industry worked overtime to save world's computers
[9]Are we springing into a Y2K-class nightmare?
[10]Epoch-alypse now: BBC iPlayer flaunts 2038 cutoff date, gives infrastructure game away
Invenco isn't the only software outfit to fall foul of February 29. Owners of Fastrack FS1 smartwatches have reported the clocks [11]being stuck at 23:59 on February 28 or [12]not displaying the date after . The YNAB (You Need A Budget) app was also said to [13]not recognize the existence of February 29. Meanwhile, in Japan, police could [14]not issue or renew driving licenses in Kanagawa, Niigata, Okayama, and Ehime, again thought to be due to the date.
As most Reg readers will know, tracking time is an absolute minefield in computing. Take the Y2K bug, where worldwide carnage was predicted because of systems representing years with only the final two digits, making 2000 indistinguishable from 1900.
While everything was "fine," this was mainly due to intense efforts by technology teams to expand date fields or window them, as explained in our [15]Retro Tech Week feature on the problem.
That isn't to say nothing went wrong, though. Japan losing its ability to monitor nuclear power plant safety systems, for instance, sounds less than optimal.
Then there's the [16]Year 2038 Problem , which affects systems working on Unix time – the number of non-leap seconds that have elapsed since 00:00:00 UTC on January 1, 1970 (the Unix epoch). Unix developers decided to track this as a signed 32-bit integer, but this data type is only capable of encoding up to 03:14:07 UTC on January 19, 2038, hence the name. One second later, the integer will overflow, which systems will interpret as 20:45:52 UTC on December 13, 1901.
We have all that still to look forward to, but looking back on the last time it was February 29, the world was about to end, so some temporary difficulties paying for fuel is a much rosier outcome. ®
Get our [17]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZeC4Nn@9QQDde10zCjx0WgAAAEU&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZeC4Nn@9QQDde10zCjx0WgAAAEU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZeC4Nn@9QQDde10zCjx0WgAAAEU&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZeC4Nn@9QQDde10zCjx0WgAAAEU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://www.nzherald.co.nz/hawkes-bay-today/news/february-29-allied-fuel-pumps-around-nz-ground-to-a-halt-as-systems-forget-leap-year/XEQBK5JLBZG6LO3VGUQ6Q2WGC4/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZeC4Nn@9QQDde10zCjx0WgAAAEU&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://www.theregister.com/2024/02/09/it_incident_report_the_clock/
[8] https://www.theregister.com/2024/01/17/y2k_feature/
[9] https://www.theregister.com/2022/03/16/us_senate_dst_forever/
[10] https://www.theregister.com/2022/01/17/bbc_iplayer_expires_2038/
[11] https://twitter.com/Amol_chi/status/1763046970317230119
[12] https://twitter.com/Manuvktr/status/1763057415417901311
[13] https://www.reddit.com/r/ynab/comments/1b27jpo/funny_glitch_for_leap_year_repeating_scheduled/
[14] https://japannews.yomiuri.co.jp/society/general-news/20240229-171789/
[15] https://www.theregister.com/2024/01/17/y2k_feature/
[16] https://theyear2038problem.com/
[17] https://whitepapers.theregister.com/
Re: Don't people test edge cases any more?
As implemented by numerous good libraries that handle time.
The real problem is that people assume they understand time and date. It is THE most difficult subject. Let alone time zones and leap seconds. A limited [1]compiled list of falsehoods is just the beginning. Or take a look at [2]days that were removed .
Do you think year 0 (zero) exists?
[1] https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca
[2] https://www.timeanddate.com/calendar/julian-gregorian-switch.html
Oh, come on - this is elementary
Dealing with February in leap years is an exercise in basic programming. If programmers cannot cope, or do not think, about this then they should not be in the job.
Having said that: there are many out there who are not competent :-(
Re: Oh, come on - this is elementary
Look on it as a regular test to find out which of those who entered the job market in the last four years should never have been sat in front of a keyboard, at leas, not one connected to anything. Wasn't it 1988 when a lot of Sun systems crashed? And before it even got to February I think. And my then manager's multi-page "Is it Friday yet" function couldn't tell when it was Friday.
Add the Swedish ICA supermarket chain to that list
They run thousands of supermarkets and pharmacies in Sweden and were unable to process credit card payments until about three this afternoon.
D'oh!
After 2038, assuming the human race is still around, we'll need to cope with the fact 2100 ISN'T a leap year...
After 2038, assuming the human race is still around, we'll need to cope with the fact 2100 ISN'T a leap year...
I would hope by then we have the technology to ensure that it will be. What else is the International Earth Rotation Service for? (Get pedalling!)
And yet 2000 was a leap year, which meant that anyone who only partially understood the rules would get caught out. If you only knew the "every 4 years" part, you'd be fine. If you remembered the "except every 100 years" and forgot the "unless it's the 400 year mark", you'd get it wrong. One of those occasions where being mostly wrong was better than being mostly right...
As for 2100 - there's still a push from some to get rid of leap years/days, so we may not be working with the current calendar by then anyway. Which means we'll likely have other software bugs in date functions to deal with. The three certainties in computing: BGP errors, DNS failures and incorrect time/date functions.
The three certainties in computing: BGP errors, DNS failures, incorrect time/date functions, and off-by-one errors.
My leap year tale
Exactly 40 years ago, I was working for an IT company which supplied software for pathology labs in hospitals - basically databases of results of blood tests, urine tests, and other unmentionable things.
Quality wasn't very good, but, having been there for only a year, I was trying to improve it.
Feb 29 rolled around, so I sat back and waited for the phone to ring. Nothing. No complaints. Had we got through it? No. The next day, March 1st, the complaints came in.
At some time in the previous four years, before I joined, someone had added a "delta check" facility to the software. This checked a patient's latest results against their previous results, and raised an alarm if they were changing too quickly.
Whoever programmed the delta check had forgotten about February having 29 days every four years. So when it compared new results against older ones, it calculated the time difference to be 24 hours less than it really was... and all hell broke loose as a large number of patients were flagged as needing attention.
Only good thing about it was that eight years later, New Scientist magazine published an article which I had written about it. I had realised that in 1992 they would have an issue actually dated 29th February, so I submitted an article recounting the above leap year woes, and then looking forward to 01 January 2000 - one of the early mentions of what became known as the Millennium Bug.
The next week they published a letter by one Arthur C Clarke, saying "interesting article, but I described this problem, and a solution, in my book......". I later saw several very similar letters from him, on other topics, so he must have had a standard template that he just added the appropriate details to before firing it off to the magazine.
First they came for the leap seconds, then they came for the leap days...
People are already campaigning to abolish leap seconds. How long before they are clamouring to abolish leap days?
Why is this a problem? I spent 35 years as a computer programmer and never once encountered a problem with February the 29th. One of the Amstrad CPC mags back in the 1980s published a BASIC function that could tell you the day of the week for any date going back hundreds of years. It could even be modified to handle the various leap days when the Gregorian calendar was adapted around the world (eg;in protestant countries 11 days were removed from September in 1752).
If anyone's code is confused then whoever wrote it made a right bog of it.
Back in those day though we had Analysts, Programmers, DBA and other specialists,
Now half of development is by lowest cost script kiddies.
I've just been part of setting up a new office in India, interviewing supposedly senior developers. Watching their eyes flicking around when I asked questions, resulted in the same two responses from me:
"Are you reading from Post-It-Notes all over your wall?"
"Are you looking this up on the Internet?"
I even told one guy that ChatGPT gave a better summary than he did trying to read from Wikipedia!
My senior people in the new India office are of equivalent standard of my first year summer holiday interns when they go back to Uni to learn more.
The bean counters just see wage costs, not the amount of teaching time we have to put into these people, fixing their bugs, etc. until they leave as soon as they think they have learned enough to get the next job.
For a cheaper site, I prefer Romania.
They speak better English
They are closed to Central European Time
They are loyal to the company
But again the bean counters kyboshed that idea.
If they only they had some prior warning this extra day that happens every four years was going to happen. The concept of leap year has only been around since the 3rd century B.C. and introduced into the Gregorian calendar in 1582 so it's understandable they haven't got the hang of it yet. I wish them luck in 4 years time when it unexpectedly happens again for the 112th time.
My automatic watch says it's 29th, what's the problem?
Owners of Fastrack FS1 smartwatches have reported the clocks being stuck
OK, I can just about accept that a few things like petrol pumps might go wrong, due to some amateurs somewhere not thinking too carefully when hacking out code. But come on, a watch, which has the one main function of working with date and time............. smart that most definitely is not.
Time to go
> February 29
Also, it's the day many people don't get paid for working.
If you are paid weekly, then the extra day just forms part of the normal working week and employers pay their staff for the leap-day.
But if you are paid monthly, then you get the same amount fof February 2024 as you got for February 2023 (assuming no intervening pay rise - an increasingly common complaint). Even though you work an extra day in 2024.
Don't people test edge cases any more?
Text required so might as well be this pedantic note
- it's not "divisible by 4" as there are 365.2425 days in a year, not 365.25. So it's divisible by 4 unless divisible by 100 unless divisible by 400.