The national law enforcement background check portal was down today, I wonder if the leap day had anything to do with it.
Ask HN: Did you encounter any leap year bugs today?
101–110 of 498 posts
Re: Ask HN: Did you encounter any leap year bugs today?
#102Uber is down in Mexico City
Re: Ask HN: Did you encounter any leap year bugs today?
#103We have a product that uses ChatGPT via the API, using the 3.5 turbo version. Our query involves some dates. Instead of giving back text like it usually does, today it has been giving errors because it does not think 2024-02-29 is a valid date.
This is easy to reproduce with the web interface, at least sometimes [0]. It start out by saying it's not a valid date and then as it's explaining why it isn't it realizes its mistake and sometimes corrects itself.
[0] https://chat.openai.com/share/37490c9f-81d6-499f-b491-116536...
Re: Ask HN: Did you encounter any leap year bugs today?
#104Yes. Be mindful about if your industrial firmware really needs to know the datetime..
Re: Ask HN: Did you encounter any leap year bugs today?
#105Our ETL process is heavily monitored so we never miss a days data, but we got a surprising error "cant build aggregates - missing data, aborting MV refresh, data will be a day old". It was the year to date (YTD) calculation - no data for 29/2/2023 to compare to today.
This is why -365 days can be better than -1y.
Frankly unless you've considered it ahead of time and thought you'd handled it, IMO you want the error. What's the correct thing to do here? I don't think it's necessarily -365d, it might be, but if I was GP I'd be glad for the chance to consider it and decide what's correct - instead of it just blowing up or even worse silently going whichever way's wrong and undetected for a while.
Re: Ask HN: Did you encounter any leap year bugs today?
#106Earlier quoted context omitted.
Since they mentioned a clean up script, I assume they could easily just use 365 days for that use case.
But then it'll be off by one day for the rest of this year. And someone will notice that they no longer have March 1 2023-March 1 2024 in their chart, but March 2 2023
It's a cleanup script. I bet nobody cares it's off by one day. Also I doubt a cleanup script has a charting function.
Everything is use case dependent. Sometimes the use case is unimportant enough that mistakes are okay.
Re: Ask HN: Did you encounter any leap year bugs today?
#107I had a few [datetime].replace(year=[current year]+n) in python where n is not divisble by 4 e.g. 2,10
This is in code we use for scheduling
Re: Ask HN: Did you encounter any leap year bugs today?
#108Earlier quoted context omitted.
As mentioned by sibling comments, it's because you're not specifying a year. If you change the day to the 28th you'll see that it defaults to the year 1900: >>> datetime.strptime('Feb 28 04:55:03.687', '%b %d %H:%M:%S.%f') datetime.datetime(1900, 2, 28, 4, 55, 3, 687000) >>> datetime.strptime('Feb 28 13:37:06.942', '%b %d %H:%M:%S.%f') datetime.datetime(1900, 2, 28, 13, 37, 6, 942000)
That makes it weird though, because 1900 was a leap year? I sort of get it, but it's a slightly odd and inconsistent decision. Edit: no it's not, it's absolutely correct, leap years just aren't as simple as I thought!
1900 was not a leap year... It's 0 mod 4, yes, but it's 0 mod 100 and not 0 mod 400
Re: Ask HN: Did you encounter any leap year bugs today?
#109Re: Ask HN: Did you encounter any leap year bugs today?
#110I did, actually!
A couple date form fields on AWS had their date incorrectly set to 2024/02/28 instead of 2024/02/29. Not mission critical, but it is something :D.