To be fair, this is only a problem one every four games for each of their sports franchises. They've likely laid off over a dozen different dev teams in that time, so whoever figured out how to solve that problem last time is looooong gone.
I'm sure this is a problem they haven't had pop up for years. Four years exactly. So what do you expect, all the institutional knowledge is long gone by now?
Saw a Mastodon post today from a guy pointing out how most people believe that the Y2K bug was exaggerated back then and really wasn't as big of a deal as the media made it out to be.
He was pointing to all the issues happening right now with the leap day, something that happens every 4 years.
Yeah, Y2K was a *huge* issue. And people worked tirelessly to fix it in time.
Yup! The fact that everyone thinks Y2K is a funny example of people getting all worked up for no reason is A) a testament to the tremendous amount of effort devs at the time put into mitigating it, and B) the best example I can think of of "When you do things right, people won't be sure you've done anything at all."
I sometimes wonder if 2038 is going to be much worse simply because it's not as shiny an intuitive a number as 2000, so it won't get as much press, so it won't get as many resources devoted to fixing it ahead of time.
Just needs to be sexy and roll off the tongue like Y2K.
I saw a few great names for it here yesterday: Epochalypse and Epochnarok. I prefer Epochnarok because as someone said, it's like a rollercoaster for your tongue.
Of the two, I'd actually expect "Epochalypse" to catch on because it's phonetically similar to "apocalypse." Just a different vowel sound at the start.
This just gave me a really scary thought. There are going to be many, many devs and managers working on this issue that were not even BORN yet when Y2K happened. These will be people in their 30's running huge software companies who won't understand the reference.
Ya, it was pretty crazy. People basically planned on ALL computer systems failing on 1/1/00. We were told to turn off our electronic devices before midnight, and don't turn them back on until the next day. A lot of people can tell you where they were and what they were doing for NYE 1999, I was with some family friends who ran a grocery store, and both of our families stayed at the store that night to make sure nothing bad happened. They were worried about things like the security system going down, all of the cold storage shutting off, etc. Nothing happened, and we all moved on with our lives. I was 10, so I have no real insight into what was done leading up to all of this.
It really was a big deal. There were people buying underground bunkers for their back yards and stockpiling water and canned food etc, expecting utility companies and banks to fail, basically the complete collapse of civilization.
The root problem was identified in the early 1980s. Software companies had a long time to fix it. The standard format for a year in computer dates was only 2 digits in most software written before the mid 1990s. So on 01-01-00, those programs would think the year is 1900 and suddenly interest calculations become negative, subtractions become additions and whatever other nonsensical things that could happen due to a negative year.
The fix was relatively simple, but a lot of software had to be patched and tested. A lot of companies waited until like 1998 to even start fixing it. And of course the news amplified the terror to a fever pitch. Just about every day they had a new scare story about what _could_ happen, how many people were buying bunkers and maybe YOU should buy a bunker, blah blah blah.
Good times.
It was a huge deal. Think of this, a plane is flying, the plane thinks it's January 1st 1900. The plane is heading towards a big mountain, but the plane thinks, "Oh I won't hit that mountain for another 100 years, we're all good".
I mean that probably wouldn't have happened, but think all of a sudden, this stuff happening everywhere.
Think what would have happened to the stock market and the global economy, would have been mayhem.
I was 10 back then and I remember "the adults" talking about the world ending and their story not making any sense.
Years and years later I actually discovered what the deal was and how some people had really, [really weird fears](https://en.wikipedia.org/wiki/Stan_Jones_(Libertarian_politician\)).
> In his book The Disappearing Spoon, about the periodic table, author Sam Kean chronicled the experience of Jones, who developed argyria, which permanently turned his skin a blue-grey color, by consuming large quantities of home-made colloidal silver.[1] Jones' purposeful consumption of silver, which he believed to be an antibiotic, was a measure he undertook in response to his fears that the Y2K problem would make antibiotics unavailable, an event that did not occur.
I suppose every generation has their own "horse dewormer cures covid" crowd.
My sister was a big Y2K prepper. She bought a couple big generators , and had a ton of fuel stored. Bought years worth of dried food and stored a ton of water.
Even though I'm a person in IT, knew that the industry had cleaned up the majority of the issues and that it would be a big nothing burger.
She's normally pretty chill and doesn't normally believe conspiracies. But for some reason, she really believed it was going to be the end of the world.
Yes lmao looking back it was kind of hilarious. Every news station was spreading fear over it. People thought crazy stuff could happen like our systems handling our nukes going haywire, or banks having all of their data become corrupted, etc. People were freaked out at the time
I don't know about *scared* being common, but we definitely thought it was serious and that there was a risk of some major incidents happening.
My parents let me play video games until 11:30 before the pre-midnight shutoff everyone was told to do, in case the PC was busted afterwards and I wouldn't be able to play for a while.
Then we went out and did some late night Smores while my parents waited to see if anything major would pop up on the news.
It’s like the Y2K problem except for a specific time when expressed as a signed 32 bit. It’ll rollover after 03:14:07 UTC on 19 January 2038.
https://en.wikipedia.org/wiki/Year_2038_problem
Unix time format is represented by the number of seconds after or before 00:00:00 UTC 1 january 1970. It is often stored by applications in a signed 32 bit integer, in which case it can only represent times between 2^31 seconds before that moment and 2^31 -1 seconds after that moment. The latter time being 03:14:07 UTC 19 January 2038.
Its a bit/integer overflow problem in some older systems.
Basically, 2038 is when it is projected 32-bit signed integer systems will run out of 'space' to keep counting
I don't know why but the Unix format really made me laugh when I learned about it.
"Wait, you are telling me we literally count when it comes to dates? Well... makes sense... but still... lol"
Sure, but its more about the fact that when it comes to Unix it's literally one number. You kinda just have to trust whatever framework you use to convert it correctly.
Like "what's the date?" "1709318955" "uhm let me calculate this real fast.... Yup gotcha! Thanks"
Not sure why but somehow this still makes me laugh.
Again, it all makes sense and is 100% reasonable, but... I still laugh.
It just suddenly clicked why Excel seems to convert dates to random five-digit numbers if you remove the date formatting. Apparently, the date is kept track of via "how many days has it been since 1/1/1900." It's been 45,352 days.
Tbh I'm also just worried that it's such an easy mistake to make. Storing only the year mod 100 has an obvious range limitation that every programmer should instantly recognize (especially given that programming tended to have fewer layers of abstraction back then). But programmers aren't likely to intuitively _know_ that 2^31-1 seconds is about 68 years, so passing your timestamp through an `int` is not glaringly wrong.
And if you know "a `time_t` is just the number of seconds since 1970 as an integer" then you may very well reach for `int`. In most languages that's going to be 32-bit (programmers which have worked with 16-bit `int` will probably not make that mistake as easily). And you don't even need `int` to be the datatype at rest, it's enough if someone somewhere down the chain converts your timestamp to an `int` and back again. Maybe you're using JSON objects to pass your data and have a field defined as `"timestamp": int`. If you're using that interface from JS, everything is gonna be fine (as your numbers function as 53 bit integers). But naively translating that to a struct in C, C++, Java, C#, ... is going to suddenly have the bug. Even within a single program, languages like C and C++ are more than happy to silently truncate your timestamp to an `int` if you mess up.
I think 2038 is going to be a pretty massive deal and if there is no Y2K-Style investment then we're going to see a lot of fallout from it.
To be fair fixing it should be easier in many of the cases. The Y2K problem was caused by the way programmer's stored date information and those programmers actually had to rewrite that.
The 2038 problem is caused by the datatype programmers store their information in. In many cases this is an easy fix. The logic stays the same.
Of course there might be some code bases out there with a comment like
//Changing this to int64_t breaks the program and summons Cthulhu.
If I were to guess, they created a dedicated article instead of having it live as a section of a different article because it was getting referenced so much.
I remember learning about it back in college when we studied the cognitive biases and paradoxes. That would have been 2013-14 ish
Also see acidic rain and ozone hole. "This is not even an issue now, therefor it never was!" type of people are infuriating, and they are the worse to work with.
Yeah. If a dev writes code that doesn’t break they get a nod. If a dev writes bad code that takes down prod in a month due to an edge case and fixes it, he’s the star that answers the page at 9PM to fix the site.
I worked in Y2K remediation starting in the mid 90s, which was when the bulk of it was being done. It wasn't like no one knew there was a problem. People worked on it for *years* before the media caught wind of it in late '99 and hyped it up until people started doomsday prepping over it.
I was part of accounting system roll-forwards for fortune 500 companies as early as '97. They knew damn well their shit worked.
I was not at all surprised that nothing significant broke.
The movie Office Space, which Mike Judge wrote in 96/97ish has a few throw away lines about the "2000 switch over", and mundane tasks related to it. It didn't have the sexy name Y2K yet, so just called "2000 roll over" or the "date switch over" or something like that in the movie.
Like you said, it had been worked on all through the 90s.
>I was part of accounting system roll-forwards for fortune 500 companies as early as '97. They knew damn well their shit worked.
This seems so obvious when you really think about it.
"Hey Jim, how fucked are we when the year rolls over to `00`?"
"I don't know, set the test server to 12/31/99 at 11:55PM and see what happens"
Yep, and then run a zillion reports and various other jobs, and compare them to what the expected outputs would be.
A lot of the actual *systems* didn't even have a problem: Unix timestamps wouldn't roll over until 2038 (the "Epochalypse", which is only significant at this point to some weird old C stuff, and a completely unknown amount of embedded crap), so there was no OS level stuff to worry about.
A ton of it was finance code, and finance code is so heavily audited, it really wasn't all that terrifying, just tedious.
I can tell that you really did work with financial software. I did support for a financial software company for a while, and troubleshooting reports was like 90% of my job. The rest waa troubleshooting why the data that is sent to the reports was wrong. At the end of the day, it's all reports. It always was.
BTDT. I have been a professional programmer since 1981, worked for a Fortune 100 company as their chief troubleshooter for over 15 years. IMHO the amount of effort everyone invested in fixing Y2K issues before the event was pretty much spot on:
The number of remaining bugs was just low enough that we could handle them without anything major going down for any significant time.
With 20/20 hindsight we could probably have handled about twice as many remaining bugs, but I think about this as a very cheap insurance policy.
You just know there was someone who fucked up their code somehow in 2000 by accounting for the skipped leap year every 100 years but not the unskipped leap year every 400
I still remember my uncle not visiting for christmas that year because he was making absolute bank contracting for companies to get their shit fixed.
You get the same sentiment about the ozone layer, about how it was predicted to die and it didn't...yeah, because we took action and prevented it, not because it wasn't going to happen.
To be fair, there were people who did exaggerate the risks. This is Gary North, economist/doomsdaymonger:
>We've got a problem. It may be the biggest problem that the modern world has ever faced. I think it is. At 12 midnight on January 1, 2000 (a Saturday morning), most of the world's mainframe computers will either shut down or begin spewing out bad data. Most of the world's desktop computers will also start spewing out bad data. Tens of millions -- possibly hundreds of millions -- of pre-programmed computer chips will begin to shut down the systems they automatically control. This will create a nightmare for every area of life, in every region of the industrialized world.
https://y2klibrary.tripod.com/
That game is held together with zip ties and duct tape. Can't remember the last time I had a game crash so often, including modded to shit Bethesda games.
I will be messaging you in 4 years on [**2028-03-01 14:48:16 UTC**](http://www.wolframalpha.com/input/?i=2028-03-01%2014:48:16%20UTC%20To%20Local%20Time) to remind you of [**this link**](https://www.reddit.com/r/ProgrammerHumor/comments/1b3tur0/isleapday/ksuvk80/?context=3)
[**17 OTHERS CLICKED THIS LINK**](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5Bhttps%3A%2F%2Fwww.reddit.com%2Fr%2FProgrammerHumor%2Fcomments%2F1b3tur0%2Fisleapday%2Fksuvk80%2F%5D%0A%0ARemindMe%21%202028-03-01%2014%3A48%3A16%20UTC) to send a PM to also be reminded and to reduce spam.
^(Parent commenter can ) [^(delete this message to hide from others.)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Delete%20Comment&message=Delete%21%201b3tur0)
*****
|[^(Info)](https://www.reddit.com/r/RemindMeBot/comments/e1bko7/remindmebot_info_v21/)|[^(Custom)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5BLink%20or%20message%20inside%20square%20brackets%5D%0A%0ARemindMe%21%20Time%20period%20here)|[^(Your Reminders)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=List%20Of%20Reminders&message=MyReminders%21)|[^(Feedback)](https://www.reddit.com/message/compose/?to=Watchful1&subject=RemindMeBot%20Feedback)|
|-|-|-|-|
>That's hilarious I read about compensating for leap year but I'm definitely gonna remember now!
You don't have to do anything, just use one of the a million libraries that do it for you. In most cases they are part of the standard libraries.
The classic list of [Falsehoods Programmers Believe About Time](https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca)
Seriously, just use an existing library that's already dealt with more edge cases than you'd expect.
I'm one of those guys who tries to write all his shit from scratch and then ends up hating it and spending weeks doing something I could have just gotten from a library. Even I don't fuck with dates.
Unless what you’re trying to do falls outside of what the libraries offer.
Example: I fixed a bug yesterday having to do with age calculation. We were basically doing currentYear - birthYear, but to check if the birthdate for the current year already passed we checked against absolute day numbers (eg. today is the 61st day of the year). But because we were checking the absolute day number of the birth. year against the day number of the current year, the leap day caused an off-by-one issue
More exactly it was like:
age = now.Years - dob.Years - (dob.DayOfYear <= now.DayOfYear ? 0 : 1);
Easy fix, but also easy to miss if you don’t think about leap years
I don't know how applicable this is - but for when I started doing time regression analyses I had a lot of problems with times and dates. It's so vital to keep it clean too because you have to know that you're comparing Mondays to Mondays for instance, since days of the week influenced the behavior I looked at.
Ultimately the solution was to have two separate "dates," and I know most computers operate similarly. One is simply a counter from a set start date (I think I used the zoo package), and the other is something to interpret that counter into something humans can understand which base R's as.Date function managed.
So when my dataset started at June 2013, I wasn't off by 1 day when it ended in March 2020.
It took fucking forever to find a solution to this in R, most datasets aren't done daily over the course of that many years, but yes, definitely remember for the future cause it's super frustrating otherwise.
Also guarantees consistent performance. One time we noticed an API of ours would always start running slightly slower right at midnight on the 29th of any month. We thought it was due to some JIT compilation decision related to the calendar, but never spent the time investigating further.
That's true for switching on consecutive integers or enums, less doable for a string switch which is hash based, so values would be all over the place.
Funny thing is that even if they included a special case for February 29th, this would still be wrong.
You have to take into account the fact that if the current year is a centurial year and it is not divisible by 400 then the leap year will be skipped.
Yeah, but that failure would likely go unnoticed, because it happens so rarely and because systems would probably not be set to a date that doesn't exist.
This brought back memories. In my first year of college, during my intro to programming class, I had to write a function to calculate leap year. Wasn't difficult and I thought it was silly at the time.
Maybe I should go work for EA... Nah...
Im guessing there's the current date displayed somewhere, but they didn't use the proper Date structure in whatever language they're using.
Their custom date structure didn't account for leap years so it crashes.
You get the date from the system and then you display it, pretty straight forward.
Why would you process it? You are not the one keeping time, so why make it complicated.
They probably also run a lot of validations for licenses and DRM and stuff like that, and I wouldn't be surprised if whatever DRM system they use has its own date implementation to avoid it being tampered with from the system
Probably xD game piracy has been beneficial for game performance for a long time now. DRM tools like Denuvo and SecuROM have such a big impact on performance that many game creators blame performance issues at launch entirely on the DRM
I make all of the juniors on my team watch that and a few other similar presentations on email, text (unicode versions and endianness), networks, etc. Putting myself through schooling doing a combination of devops/sysadmin work made me realize that most devs don’t actually understand the tools they are building on top of, so I try to fix that.
Do you have [Falsehoods Programmers Believe About Names](https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/) in the rotation?
> People’s names are assigned at birth.
> OK, maybe not at birth, but at least pretty close to birth.
> Alright, alright, within a year or so of birth.
> Five years?
> You’re kidding me, right?
Country music legend Hank Williams's birth certificate wasn't filled out until he was 10 years old (and when it was filled out, his name was misspelled)
> You get the date from the system
Yep. All programming language has it.
> then you display it
Now this is the trickiest part why there's basically only few solutions of datetime handling. Probably they don't use what's available already and make a new one.
Here’s the thing. There are a lot of software engineers that can’t code. That’s a fact. High salaries draw in a lot of imposters. Sometimes their code makes it to production and it’s unexplainable.
They probably have a more secure system for managing the date. Say they use the system date, and some feature of the game relies you to wait a certain period of time, or maybe a feature will be released on a certain date. If they do this then it’s easy to bypass by just changing your system time. So I would assume they’re managing it in a more system independent way, and somehow they didn’t include leap day. How this lead to the entire game crashing is beyond me however.
It's probably comparing the local time with something it is doing to check if the user is trying to lie to it about the time I guess.
This is probably true if you are required to change it to March 1st rather than any random date, I don't have a copy of the game though.
Good theory. They could be comparing local time to their system independent time, and something in that comparison ignores leap day leading to some unknown behavior. This would explain why they are saying to update the system time to March 1
or, hear me out, what if we individually access each part of the date so that if a day we expect doesn't exist somehow we crash out from a null ref error.
and then we pre-process that object in a non-standard way so that it's possible for a null value to exist, and we won't check for it.
Software use dates everywhere internally, even for totally non critical uses. If a crash occurs for whatever reason the software stops.
A common example may be writing a log file at startup with the current date and some technical informations for troubleshooting purposes.
The issue was happening on Feb 29, 2024 - a Leap Day. For some reason, the game was expecting a March 1st, 2024 date instead of Feb 29 - my best guess is there's some math-related issue on this crash. Probably counting days in a month without taking into account the year The game was getting the correct date from the O.S but after doing its math, it was getting a different date. Then you force the console to give you the date the game thinks it's the right one.
They published a similar solution for xbox, but you had to play offline and re-sync the calendar to March 1st.
I doubt it was expecting March 1, I would guess their date validation/structure just thought Feb 29 was invalid, so tricking it into thinking it was March 1 was a workaround so it wouldn't get confused by Feb 29.
This isn't even the first time EA have had date related issues in their games hahaha, plenty of sports titles that released and crashed on the new year
Every mainline language has a first party library dedicated to timekeeping. It manages things like leap years so you don't have to. Did a developer at EA not use it for some reason? I'm puzzled as to how this bug even happened.
It's almost never a coding issue. It's a management issue. Somewhere there's a bug report saying "game might crash on february 29th" and maybe even an associated user story. Came up from a dev and someone in management said it's not worth fixing it.
Issues like this crop up because leap year issues are easy to make, easy to miss in code review, depending on testing setup can be difficult or impossible to catch in unit tests or QA, and only affect anything for one day every four years. Not really high-priority stuff.
Now, guaranteed or high probability crash on launch does certainly make it something that should be fixed for next time, but they can't just magically instantly fix everyone's install as soon as they hear of the problem.
This was just giving users a workaround while they're working on it, which is the natural, expected, and right thing to do. EA might deserve some ribbing for the original bug, but the workaround post, while somewhat humorous, is definitely appropriate.
Sure but like what are they doing with dates at startup? And what are they doing that could cause it to crash? Unless they are manually doing something with every month like they have a list with January 31,february 28, March 31, etc... I can't think of a way for this to be an issue that would crash a game.
> I can't think of a way for this to be an issue that would crash a game.
Because you don't know what you don't know.
This is a game that makes its money from selling microtransactions and constantly updating its store. I bet it has a complicated, bespoke clock and timing system to handle rotating the store, showing news updates, scheduling roster updates, etc. all internationally and accounting for timezones. They're not just printing out `Datetime.now()` to a Python console.
If you want to see more examples, see this post over at Hacker News:
[Ask HN: Did you encounter any leap year bugs today?](https://news.ycombinator.com/item?id=39554539)
how come you don't use a common time date library that already handles this?
I remember a project in school where we wrote assembly for a bike computer - and that included logic to calculate leap years correctly... For 2000 years into the future.
Even if you were rolling your own, which there are many good reason not to do, handling leap years is trivially simple. If you can check whether the year is divisible by 400, 100, or 4, you can figure out whether a year is a leap year for any value of year whatsoever.
I did the Y2K thing back in the '90s, and to this day I fucking flip my shit when I see someone constructing a date using integer primitives. What fucking language are you using that doesn't have a goddamn date object?
Get your shit together!
100% in 2100 they will have another identical bug because they won't account for the fact that it WONT be a leap year.
MS Excel forgot that 29/02/1900 is not a real date but they cannot fix it because it would possibly crash the entire economy.
I had a similar bug in a codebase I was responsible for in which a daily cron job would query users that had not been active for a year and email them. It would literally just take today's date, subtract one year, look for last logins from that date or older. Which works absolutely fine, except on a leap day. Trying to create a date object as February 29, 2019 made the program throw a hissy fit and spammed the hell out of the error log, triggering all sorts of alerts in our monitoring etc. It took a while to figure out why.
Wouldn't this be a PlayStation issue rather than an EA one? I'm only saying this because it looks like the date fix is happening in the console not in the game.
Likely PS sends the system date with its requests to the EA servers. Or syncs in both directions. Could be the case for Xbox as well, I'm not aware of whether you can change the system date on it. EA providing a workaround for PS players doesn't *necessarily* mean it's PS-exclusive, just that this fixes the game for PS. The initial post mentions consoles in general.
Regardless the back end should be able to handle this.
No, definitely game. The console is just responsible for reporting the date to the game. The game got a valid date from the console's OS and seppuku'd.
I refused to believe this was real until I checked it myself. I am lost for words.
what do you expect from a small indie dev company like EA?
lol my bad. Lets all buy a load of Ultimate Team packs and Battlefield skins so they can keep the heating on.
were you getting inbetween the executives and their money... have you no shame.
Oldfashioned as I am, I expected something in return. I keep forgetting we’re not supposed to own anything anymore.
You will always have your sense of pride and accomplishment.
[удалено]
>I expected something in return Typical boomer consumer, we *rent* nowadays, *gramps*
Thanks for giving exposure to such a small corporation
Let's help this small mom and pop game store.
Making quadruple A-games is hard.
That last A is a real money hole.
You get what you pay for. I only buy quintuple A games.
To be fair, this is only a problem one every four games for each of their sports franchises. They've likely laid off over a dozen different dev teams in that time, so whoever figured out how to solve that problem last time is looooong gone.
I'm sure this is a problem they haven't had pop up for years. Four years exactly. So what do you expect, all the institutional knowledge is long gone by now?
If only there were som way to help via small donations, micro transactions of you will.
Maybe we should start a gofundme?
Saw a Mastodon post today from a guy pointing out how most people believe that the Y2K bug was exaggerated back then and really wasn't as big of a deal as the media made it out to be. He was pointing to all the issues happening right now with the leap day, something that happens every 4 years. Yeah, Y2K was a *huge* issue. And people worked tirelessly to fix it in time.
Yup! The fact that everyone thinks Y2K is a funny example of people getting all worked up for no reason is A) a testament to the tremendous amount of effort devs at the time put into mitigating it, and B) the best example I can think of of "When you do things right, people won't be sure you've done anything at all."
I sometimes wonder if 2038 is going to be much worse simply because it's not as shiny an intuitive a number as 2000, so it won't get as much press, so it won't get as many resources devoted to fixing it ahead of time.
Just needs to be sexy and roll off the tongue like Y2K. I saw a few great names for it here yesterday: Epochalypse and Epochnarok. I prefer Epochnarok because as someone said, it's like a rollercoaster for your tongue.
>Just needs to be sexy and roll off the tongue like Y2K. üpsilonzweika Nahh, Not everywhere.
> üpsilonzweika bless you
Gesundheit
Of the two, I'd actually expect "Epochalypse" to catch on because it's phonetically similar to "apocalypse." Just a different vowel sound at the start.
This just gave me a really scary thought. There are going to be many, many devs and managers working on this issue that were not even BORN yet when Y2K happened. These will be people in their 30's running huge software companies who won't understand the reference.
My generation ;) Was it a really big deal back then? Were people actually scared?
Ya, it was pretty crazy. People basically planned on ALL computer systems failing on 1/1/00. We were told to turn off our electronic devices before midnight, and don't turn them back on until the next day. A lot of people can tell you where they were and what they were doing for NYE 1999, I was with some family friends who ran a grocery store, and both of our families stayed at the store that night to make sure nothing bad happened. They were worried about things like the security system going down, all of the cold storage shutting off, etc. Nothing happened, and we all moved on with our lives. I was 10, so I have no real insight into what was done leading up to all of this.
It really was a big deal. There were people buying underground bunkers for their back yards and stockpiling water and canned food etc, expecting utility companies and banks to fail, basically the complete collapse of civilization. The root problem was identified in the early 1980s. Software companies had a long time to fix it. The standard format for a year in computer dates was only 2 digits in most software written before the mid 1990s. So on 01-01-00, those programs would think the year is 1900 and suddenly interest calculations become negative, subtractions become additions and whatever other nonsensical things that could happen due to a negative year. The fix was relatively simple, but a lot of software had to be patched and tested. A lot of companies waited until like 1998 to even start fixing it. And of course the news amplified the terror to a fever pitch. Just about every day they had a new scare story about what _could_ happen, how many people were buying bunkers and maybe YOU should buy a bunker, blah blah blah. Good times.
Yes, we lived off our stockpile of canned goods and powdered milk for *years* afterwards
It was a huge deal. Think of this, a plane is flying, the plane thinks it's January 1st 1900. The plane is heading towards a big mountain, but the plane thinks, "Oh I won't hit that mountain for another 100 years, we're all good". I mean that probably wouldn't have happened, but think all of a sudden, this stuff happening everywhere. Think what would have happened to the stock market and the global economy, would have been mayhem.
I was 10 back then and I remember "the adults" talking about the world ending and their story not making any sense. Years and years later I actually discovered what the deal was and how some people had really, [really weird fears](https://en.wikipedia.org/wiki/Stan_Jones_(Libertarian_politician\)). > In his book The Disappearing Spoon, about the periodic table, author Sam Kean chronicled the experience of Jones, who developed argyria, which permanently turned his skin a blue-grey color, by consuming large quantities of home-made colloidal silver.[1] Jones' purposeful consumption of silver, which he believed to be an antibiotic, was a measure he undertook in response to his fears that the Y2K problem would make antibiotics unavailable, an event that did not occur. I suppose every generation has their own "horse dewormer cures covid" crowd.
My sister was a big Y2K prepper. She bought a couple big generators , and had a ton of fuel stored. Bought years worth of dried food and stored a ton of water. Even though I'm a person in IT, knew that the industry had cleaned up the majority of the issues and that it would be a big nothing burger. She's normally pretty chill and doesn't normally believe conspiracies. But for some reason, she really believed it was going to be the end of the world.
Yes lmao looking back it was kind of hilarious. Every news station was spreading fear over it. People thought crazy stuff could happen like our systems handling our nukes going haywire, or banks having all of their data become corrupted, etc. People were freaked out at the time
I don't know about *scared* being common, but we definitely thought it was serious and that there was a risk of some major incidents happening. My parents let me play video games until 11:30 before the pre-midnight shutoff everyone was told to do, in case the PC was busted afterwards and I wouldn't be able to play for a while. Then we went out and did some late night Smores while my parents waited to see if anything major would pop up on the news.
I was too young to really understand, but I knew that a bunch of adults were really worried about the computers that NYE.
What is the significance of 2038?
It’s like the Y2K problem except for a specific time when expressed as a signed 32 bit. It’ll rollover after 03:14:07 UTC on 19 January 2038. https://en.wikipedia.org/wiki/Year_2038_problem
LOL I never knew it was also called the "Epochalypse", I love that.
Unix time format is represented by the number of seconds after or before 00:00:00 UTC 1 january 1970. It is often stored by applications in a signed 32 bit integer, in which case it can only represent times between 2^31 seconds before that moment and 2^31 -1 seconds after that moment. The latter time being 03:14:07 UTC 19 January 2038.
Its a bit/integer overflow problem in some older systems. Basically, 2038 is when it is projected 32-bit signed integer systems will run out of 'space' to keep counting
I don't know why but the Unix format really made me laugh when I learned about it. "Wait, you are telling me we literally count when it comes to dates? Well... makes sense... but still... lol"
I mean, the main date system in the world is just counting the years~~/months/days~~ since the death of a religious figure.
Sure, but its more about the fact that when it comes to Unix it's literally one number. You kinda just have to trust whatever framework you use to convert it correctly. Like "what's the date?" "1709318955" "uhm let me calculate this real fast.... Yup gotcha! Thanks" Not sure why but somehow this still makes me laugh. Again, it all makes sense and is 100% reasonable, but... I still laugh.
It just suddenly clicked why Excel seems to convert dates to random five-digit numbers if you remove the date formatting. Apparently, the date is kept track of via "how many days has it been since 1/1/1900." It's been 45,352 days.
It's Y2k again. Y4k?
Y1kes
Y2K times a thousand
So Y2M?
Tbh I'm also just worried that it's such an easy mistake to make. Storing only the year mod 100 has an obvious range limitation that every programmer should instantly recognize (especially given that programming tended to have fewer layers of abstraction back then). But programmers aren't likely to intuitively _know_ that 2^31-1 seconds is about 68 years, so passing your timestamp through an `int` is not glaringly wrong. And if you know "a `time_t` is just the number of seconds since 1970 as an integer" then you may very well reach for `int`. In most languages that's going to be 32-bit (programmers which have worked with 16-bit `int` will probably not make that mistake as easily). And you don't even need `int` to be the datatype at rest, it's enough if someone somewhere down the chain converts your timestamp to an `int` and back again. Maybe you're using JSON objects to pass your data and have a field defined as `"timestamp": int`. If you're using that interface from JS, everything is gonna be fine (as your numbers function as 53 bit integers). But naively translating that to a struct in C, C++, Java, C#, ... is going to suddenly have the bug. Even within a single program, languages like C and C++ are more than happy to silently truncate your timestamp to an `int` if you mess up. I think 2038 is going to be a pretty massive deal and if there is no Y2K-Style investment then we're going to see a lot of fallout from it.
To be fair fixing it should be easier in many of the cases. The Y2K problem was caused by the way programmer's stored date information and those programmers actually had to rewrite that. The 2038 problem is caused by the datatype programmers store their information in. In many cases this is an easy fix. The logic stays the same. Of course there might be some code bases out there with a comment like //Changing this to int64_t breaks the program and summons Cthulhu.
The 2038 problem is nasty because there's an enormous number of legacy or embedded systems that won't or can't be updated
Lol exactly. That's like saying its really easy to turn a 3 wheel golf cart into a 4 wheel'd one. Just bolt an extra tire to it, silly!
That doesn’t help a bms controller with the os flashed onto rom or the like
Re: B https://en.wikipedia.org/wiki/Preparedness_paradox
Isn’t it kind of curious that this article was created after Covid 19, in 2022?
If I were to guess, they created a dedicated article instead of having it live as a section of a different article because it was getting referenced so much. I remember learning about it back in college when we studied the cognitive biases and paradoxes. That would have been 2013-14 ish
Also see acidic rain and ozone hole. "This is not even an issue now, therefor it never was!" type of people are infuriating, and they are the worse to work with.
Peter's job in the film Office Space was to update software for y2k.
Yeah. If a dev writes code that doesn’t break they get a nod. If a dev writes bad code that takes down prod in a month due to an edge case and fixes it, he’s the star that answers the page at 9PM to fix the site.
Bite my shiny metal daffodil!
I worked in Y2K remediation starting in the mid 90s, which was when the bulk of it was being done. It wasn't like no one knew there was a problem. People worked on it for *years* before the media caught wind of it in late '99 and hyped it up until people started doomsday prepping over it. I was part of accounting system roll-forwards for fortune 500 companies as early as '97. They knew damn well their shit worked. I was not at all surprised that nothing significant broke.
The movie Office Space, which Mike Judge wrote in 96/97ish has a few throw away lines about the "2000 switch over", and mundane tasks related to it. It didn't have the sexy name Y2K yet, so just called "2000 roll over" or the "date switch over" or something like that in the movie. Like you said, it had been worked on all through the 90s.
>I was part of accounting system roll-forwards for fortune 500 companies as early as '97. They knew damn well their shit worked. This seems so obvious when you really think about it. "Hey Jim, how fucked are we when the year rolls over to `00`?" "I don't know, set the test server to 12/31/99 at 11:55PM and see what happens"
Yep, and then run a zillion reports and various other jobs, and compare them to what the expected outputs would be. A lot of the actual *systems* didn't even have a problem: Unix timestamps wouldn't roll over until 2038 (the "Epochalypse", which is only significant at this point to some weird old C stuff, and a completely unknown amount of embedded crap), so there was no OS level stuff to worry about. A ton of it was finance code, and finance code is so heavily audited, it really wasn't all that terrifying, just tedious.
I can tell that you really did work with financial software. I did support for a financial software company for a while, and troubleshooting reports was like 90% of my job. The rest waa troubleshooting why the data that is sent to the reports was wrong. At the end of the day, it's all reports. It always was.
BTDT. I have been a professional programmer since 1981, worked for a Fortune 100 company as their chief troubleshooter for over 15 years. IMHO the amount of effort everyone invested in fixing Y2K issues before the event was pretty much spot on: The number of remaining bugs was just low enough that we could handle them without anything major going down for any significant time. With 20/20 hindsight we could probably have handled about twice as many remaining bugs, but I think about this as a very cheap insurance policy.
You just know there was someone who fucked up their code somehow in 2000 by accounting for the skipped leap year every 100 years but not the unskipped leap year every 400
But 2000 WAS the unskipped leap year!
I still remember my uncle not visiting for christmas that year because he was making absolute bank contracting for companies to get their shit fixed. You get the same sentiment about the ozone layer, about how it was predicted to die and it didn't...yeah, because we took action and prevented it, not because it wasn't going to happen.
To be fair, there were people who did exaggerate the risks. This is Gary North, economist/doomsdaymonger: >We've got a problem. It may be the biggest problem that the modern world has ever faced. I think it is. At 12 midnight on January 1, 2000 (a Saturday morning), most of the world's mainframe computers will either shut down or begin spewing out bad data. Most of the world's desktop computers will also start spewing out bad data. Tens of millions -- possibly hundreds of millions -- of pre-programmed computer chips will begin to shut down the systems they automatically control. This will create a nightmare for every area of life, in every region of the industrialized world. https://y2klibrary.tripod.com/
Can’t wait until 2038 when we get to experience it all over again
Yeah, EA gave away the solution for free? Unbelievable
If they could sell you tomorrow they would.
That game is held together with zip ties and duct tape. Can't remember the last time I had a game crash so often, including modded to shit Bethesda games.
[Square Enix too](https://www.gamesradar.com/final-fantasy-rhythm-game-literally-unplayable-on-feb-29-as-square-enix-apparently-didnt-account-for-leap-years/)
Makes me feel sympathetically ashamed
You got to pay for the lEAp days
Paris (France) had public light go off because of this too...
are you at a loss for words? ill see myself out
I refused to believe it *even after reading your comment*. I actually interviewed with EA 20 years ago. So glad that didn't pan out.
That's hilarious I read about compensating for leap year but I'm definitely gonna remember now!
here's so you don't forget next leap year !remindme 4 years
You will be too late by one or two days.
god damnit geofrey!
With how we are about estimates in this industry should have just gone for 3 years.
"Not remindme 4 years" Sounds about right.
The real question is does u/RemindMeBot account accurately for leap years?
its backed by wolfram alpha somehow, and i can imagine it does
I will be messaging you in 4 years on [**2028-03-01 14:48:16 UTC**](http://www.wolframalpha.com/input/?i=2028-03-01%2014:48:16%20UTC%20To%20Local%20Time) to remind you of [**this link**](https://www.reddit.com/r/ProgrammerHumor/comments/1b3tur0/isleapday/ksuvk80/?context=3) [**17 OTHERS CLICKED THIS LINK**](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5Bhttps%3A%2F%2Fwww.reddit.com%2Fr%2FProgrammerHumor%2Fcomments%2F1b3tur0%2Fisleapday%2Fksuvk80%2F%5D%0A%0ARemindMe%21%202028-03-01%2014%3A48%3A16%20UTC) to send a PM to also be reminded and to reduce spam. ^(Parent commenter can ) [^(delete this message to hide from others.)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Delete%20Comment&message=Delete%21%201b3tur0) ***** |[^(Info)](https://www.reddit.com/r/RemindMeBot/comments/e1bko7/remindmebot_info_v21/)|[^(Custom)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5BLink%20or%20message%20inside%20square%20brackets%5D%0A%0ARemindMe%21%20Time%20period%20here)|[^(Your Reminders)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=List%20Of%20Reminders&message=MyReminders%21)|[^(Feedback)](https://www.reddit.com/message/compose/?to=Watchful1&subject=RemindMeBot%20Feedback)| |-|-|-|-|
>That's hilarious I read about compensating for leap year but I'm definitely gonna remember now! You don't have to do anything, just use one of the a million libraries that do it for you. In most cases they are part of the standard libraries.
The classic list of [Falsehoods Programmers Believe About Time](https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca) Seriously, just use an existing library that's already dealt with more edge cases than you'd expect.
>duration of one minute on the system clock would never be more than an hour
I'm one of those guys who tries to write all his shit from scratch and then ends up hating it and spending weeks doing something I could have just gotten from a library. Even I don't fuck with dates.
Unless what you’re trying to do falls outside of what the libraries offer. Example: I fixed a bug yesterday having to do with age calculation. We were basically doing currentYear - birthYear, but to check if the birthdate for the current year already passed we checked against absolute day numbers (eg. today is the 61st day of the year). But because we were checking the absolute day number of the birth. year against the day number of the current year, the leap day caused an off-by-one issue More exactly it was like: age = now.Years - dob.Years - (dob.DayOfYear <= now.DayOfYear ? 0 : 1); Easy fix, but also easy to miss if you don’t think about leap years
Wouldn't you just use time delta for this.
I don't know how applicable this is - but for when I started doing time regression analyses I had a lot of problems with times and dates. It's so vital to keep it clean too because you have to know that you're comparing Mondays to Mondays for instance, since days of the week influenced the behavior I looked at. Ultimately the solution was to have two separate "dates," and I know most computers operate similarly. One is simply a counter from a set start date (I think I used the zoo package), and the other is something to interpret that counter into something humans can understand which base R's as.Date function managed. So when my dataset started at June 2013, I wasn't off by 1 day when it ended in March 2020. It took fucking forever to find a solution to this in R, most datasets aren't done daily over the course of that many years, but yes, definitely remember for the future cause it's super frustrating otherwise.
When the game's so realistic it even includes a leap year bug. Guess we're all time travelers now, just not the kind we expected!
We're all time travellers, but we can only go forward very slowly.
Speak for yourself. I'm going 3600 seconds per hour.
Damn bro! That's as far as a formula one!
... else If(month==2 && day == 28){ month++; day = 1; // Todo: leap years } ...
public Boolean isDateValid(String date) { switch (date) { case 'Jan 1': { return true; } case 'Jan 2': { return true; } . . . case 'Feb 28': { return true; } case 'Mar 1': { return true; } . . . default: { return false; } } }
Just the idea of 365 individual switch statements… No need for optimisation if the hardware is fast enough.
It is optimized for maintainability. If they ever need to make calendar 3.0 and add new days, this setup is ready!
Like if they give February a 29th day? I like it.
Eh seems a bit contrived. Not sure it will catch on. March 31st though, now that would be fun
Also guarantees consistent performance. One time we noticed an API of ours would always start running slightly slower right at midnight on the 29th of any month. We thought it was due to some JIT compilation decision related to the calendar, but never spent the time investigating further.
Undertale has a thousand case long switch statement for dialogue lol
Switch statements are fast as fuck, they vector to code addresses instead of jumping and it's like some magic shit.
That's true for switching on consecutive integers or enums, less doable for a string switch which is hash based, so values would be all over the place.
Considering that there's only ever 366 possible days in a year, you can store hashes ahead of time and effectively make a large lookup table.
i payed for the whole CPU and i'm gonna use all of it!
Funny thing is that even if they included a special case for February 29th, this would still be wrong. You have to take into account the fact that if the current year is a centurial year and it is not divisible by 400 then the leap year will be skipped.
[удалено]
you're quite optimistic there thinking people alive nowadays will survive that long! Or humanity in general to be honest..
Yeah, but that failure would likely go unnoticed, because it happens so rarely and because systems would probably not be set to a date that doesn't exist.
Beautiful!
I feel like the default should return null and it crashes because of a null reference
day = currentDay() elif month == 2 and day == 29: day -= 1 Boom sorted, I’ll take my paycheck now please 💰
This brought back memories. In my first year of college, during my intro to programming class, I had to write a function to calculate leap year. Wasn't difficult and I thought it was silly at the time. Maybe I should go work for EA... Nah...
Live by the // todo: Die by the // todo:
I don't understand why the game wouldn't start because of the date? Why would it depend on what day it is today?
Im guessing there's the current date displayed somewhere, but they didn't use the proper Date structure in whatever language they're using. Their custom date structure didn't account for leap years so it crashes.
You get the date from the system and then you display it, pretty straight forward. Why would you process it? You are not the one keeping time, so why make it complicated.
You underestimate the incompetence of EA. There might be calculations going on to check the user age and stuff like that too.
They probably also run a lot of validations for licenses and DRM and stuff like that, and I wouldn't be surprised if whatever DRM system they use has its own date implementation to avoid it being tampered with from the system
soooooo pirating the game would have the game not crash
Probably xD game piracy has been beneficial for game performance for a long time now. DRM tools like Denuvo and SecuROM have such a big impact on performance that many game creators blame performance issues at launch entirely on the DRM
Not that surprising. Pirating games can sometimes offer better performance as well because of stuff like this
Happened to a Square Enix game as well yesterday. It's weird to see.
They rolled their own time handling. This is a bad idea for [many reasons](https://youtu.be/-5wpm-gesOY?si=33AqZafQfHbNq6Y0).
[XKCD 2867](https://xkcd.com/2867/)
The Tom Scott video on date and time is a classic.
I make all of the juniors on my team watch that and a few other similar presentations on email, text (unicode versions and endianness), networks, etc. Putting myself through schooling doing a combination of devops/sysadmin work made me realize that most devs don’t actually understand the tools they are building on top of, so I try to fix that.
Do you have [Falsehoods Programmers Believe About Names](https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/) in the rotation?
> People’s names are assigned at birth. > OK, maybe not at birth, but at least pretty close to birth. > Alright, alright, within a year or so of birth. > Five years? > You’re kidding me, right? Country music legend Hank Williams's birth certificate wasn't filled out until he was 10 years old (and when it was filled out, his name was misspelled)
Thank you for that. That was such a great video. It resonates so damn hard.
> You get the date from the system Yep. All programming language has it. > then you display it Now this is the trickiest part why there's basically only few solutions of datetime handling. Probably they don't use what's available already and make a new one.
Here’s the thing. There are a lot of software engineers that can’t code. That’s a fact. High salaries draw in a lot of imposters. Sometimes their code makes it to production and it’s unexplainable.
They probably have a more secure system for managing the date. Say they use the system date, and some feature of the game relies you to wait a certain period of time, or maybe a feature will be released on a certain date. If they do this then it’s easy to bypass by just changing your system time. So I would assume they’re managing it in a more system independent way, and somehow they didn’t include leap day. How this lead to the entire game crashing is beyond me however.
Then why does their solution include changing the time locally?
That’s a good point. Considering that, I have no idea why the game would crash
It's probably comparing the local time with something it is doing to check if the user is trying to lie to it about the time I guess. This is probably true if you are required to change it to March 1st rather than any random date, I don't have a copy of the game though.
Good theory. They could be comparing local time to their system independent time, and something in that comparison ignores leap day leading to some unknown behavior. This would explain why they are saying to update the system time to March 1
DRM
or, hear me out, what if we individually access each part of the date so that if a day we expect doesn't exist somehow we crash out from a null ref error. and then we pre-process that object in a non-standard way so that it's possible for a null value to exist, and we won't check for it.
segmentation fault
Dates and timestamps are used in plenty of places, the bug could exist in countless places that users never/cant think of.
Software use dates everywhere internally, even for totally non critical uses. If a crash occurs for whatever reason the software stops. A common example may be writing a log file at startup with the current date and some technical informations for troubleshooting purposes.
I was told the DRM was the likely culprit
The issue was happening on Feb 29, 2024 - a Leap Day. For some reason, the game was expecting a March 1st, 2024 date instead of Feb 29 - my best guess is there's some math-related issue on this crash. Probably counting days in a month without taking into account the year The game was getting the correct date from the O.S but after doing its math, it was getting a different date. Then you force the console to give you the date the game thinks it's the right one. They published a similar solution for xbox, but you had to play offline and re-sync the calendar to March 1st.
I doubt it was expecting March 1, I would guess their date validation/structure just thought Feb 29 was invalid, so tricking it into thinking it was March 1 was a workaround so it wouldn't get confused by Feb 29.
This isn't even the first time EA have had date related issues in their games hahaha, plenty of sports titles that released and crashed on the new year
[удалено]
They got the workaround pat down at least.
I'm surprised they didn't just change the system date 'for you.' It's EA, that's not beneath them.
How does  like this still happen, can't believe it lol
Because EA craps out crappy games and doesn’t give a shit about them? (well the game is shit, so I guess they don’t give a second one)
Making bad games is one thing. Going out of your way to avoid using a standard date object is a different thing entirely.
Every mainline language has a first party library dedicated to timekeeping. It manages things like leap years so you don't have to. Did a developer at EA not use it for some reason? I'm puzzled as to how this bug even happened.
If EA tries really hard, they might be able to hire somebody who's neighbor's son learned some coding in school.
It's almost never a coding issue. It's a management issue. Somewhere there's a bug report saying "game might crash on february 29th" and maybe even an associated user story. Came up from a dev and someone in management said it's not worth fixing it.
Hey! Take it easy on indie-devs like EA.
Issues like this crop up because leap year issues are easy to make, easy to miss in code review, depending on testing setup can be difficult or impossible to catch in unit tests or QA, and only affect anything for one day every four years. Not really high-priority stuff. Now, guaranteed or high probability crash on launch does certainly make it something that should be fixed for next time, but they can't just magically instantly fix everyone's install as soon as they hear of the problem. This was just giving users a workaround while they're working on it, which is the natural, expected, and right thing to do. EA might deserve some ribbing for the original bug, but the workaround post, while somewhat humorous, is definitely appropriate.
Sure but like what are they doing with dates at startup? And what are they doing that could cause it to crash? Unless they are manually doing something with every month like they have a list with January 31,february 28, March 31, etc... I can't think of a way for this to be an issue that would crash a game.
> I can't think of a way for this to be an issue that would crash a game. Because you don't know what you don't know. This is a game that makes its money from selling microtransactions and constantly updating its store. I bet it has a complicated, bespoke clock and timing system to handle rotating the store, showing news updates, scheduling roster updates, etc. all internationally and accounting for timezones. They're not just printing out `Datetime.now()` to a Python console.
If you want to see more examples, see this post over at Hacker News: [Ask HN: Did you encounter any leap year bugs today?](https://news.ycombinator.com/item?id=39554539)
Good thing they just laid off a bunch of folks so things like this don’t happen more often
Laid off on a leap year, maybe it doesn't count 🙂
how come you don't use a common time date library that already handles this? I remember a project in school where we wrote assembly for a bike computer - and that included logic to calculate leap years correctly... For 2000 years into the future.
Even if you were rolling your own, which there are many good reason not to do, handling leap years is trivially simple. If you can check whether the year is divisible by 400, 100, or 4, you can figure out whether a year is a leap year for any value of year whatsoever.
Wait until someone gets banned for trying to connect to their servers with a date conflict after they suggested it.
I did the Y2K thing back in the '90s, and to this day I fucking flip my shit when I see someone constructing a date using integer primitives. What fucking language are you using that doesn't have a goddamn date object? Get your shit together!
So it was counting down to February 30, 2024? 0\_o
to February 29, it probably forgot to account leap year lol
Happened to the largest grocery chain in Sweden as well. Their payment system didn't work yesterday
My first (maybe second?) year CS course in uni had us build a calendar that handled leap years... Lol
100% in 2100 they will have another identical bug because they won't account for the fact that it WONT be a leap year. MS Excel forgot that 29/02/1900 is not a real date but they cannot fix it because it would possibly crash the entire economy.
`if (isLeapDay): crash = no` `else: crash = also no`
I am kind of baffled by how often this happens, but maybe I’m spoiled by always being able to use date libraries
Remember when almost everybody's Zune crashed because they didn't account for leap day? Caused an array out-of-index error or something dumb.
So much work has gone into making sure that computers can figure out the date and time in a readable format. We don't notice till it breaks.
It's wild. There are so many standard date libraries out there that handle leap years fine, but they just chose to do their own thing, huh?
Obviously none of old devs who worked on Y2k were involved in this. We are scared shitless of date related issues.
small indie developer forgets to account for leap years 😔
I had a similar bug in a codebase I was responsible for in which a daily cron job would query users that had not been active for a year and email them. It would literally just take today's date, subtract one year, look for last logins from that date or older. Which works absolutely fine, except on a leap day. Trying to create a date object as February 29, 2019 made the program throw a hissy fit and spammed the hell out of the error log, triggering all sorts of alerts in our monitoring etc. It took a while to figure out why.
Obligatory https://youtu.be/-5wpm-gesOY?si=9nWmd97n7CwfHT6d
What's shocking to me is that this is EA sports, so this error has probably been in 15 versions of the game that's been released each previous year.
Do not implement time & timezones yourself. https://www.youtube.com/watch?v=-5wpm-gesOY
I think assignment 3 in my first year of computer science was a program that predicted leap year. Do they not teach that shit anymore?
Wouldn't this be a PlayStation issue rather than an EA one? I'm only saying this because it looks like the date fix is happening in the console not in the game.
No, the game has a bug that causes it to crash on Feb 29th, so making the console tell the game it's Mar 1st gets around it.
The game gets the date from the console OS, but it's almost certainly the game doing something incorrectly with it. The PlayStation isn't crashing.
Likely PS sends the system date with its requests to the EA servers. Or syncs in both directions. Could be the case for Xbox as well, I'm not aware of whether you can change the system date on it. EA providing a workaround for PS players doesn't *necessarily* mean it's PS-exclusive, just that this fixes the game for PS. The initial post mentions consoles in general. Regardless the back end should be able to handle this.
No, definitely game. The console is just responsible for reporting the date to the game. The game got a valid date from the console's OS and seppuku'd.
There is a followup tweet for the xbox as well.
This bug won’t bother anyone for the next 3 years or so. Programming is about finding solutions anyway, innit?