Maybe? My paycheck direct deposit didn't show up until almost 7am. Normally it hits right at midnight.
Ask HN: Did you encounter any leap year bugs today?
41–50 of 498 posts
Re: Ask HN: Did you encounter any leap year bugs today?
#42The Casio F-91W doesn’t account for the year, it showed today’s date as Thursday, March 1st.
Thank you so much for the reminder, that would have screwed me up today :)
Re: Ask HN: Did you encounter any leap year bugs today?
#43Earlier quoted context omitted.
What is your definition of "subtracting a year"? Seems like that's a relatively ambiguous operation without more specification.
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
Re: Ask HN: Did you encounter any leap year bugs today?
#44One of the most common QA test cases when it comes to testing date and time sensitive applications.
Re: Ask HN: Did you encounter any leap year bugs today?
#45Yes, a few mildly bad things go wrong on a feb 29th. Everything that handles stuff a year from now for example. Pretty bad for a planning program. But our customers noticed and avoided that. Codebase is too ancient and brittle to even attempt to fix. Or at least boss doesn't want to invest time in it.
Re: Ask HN: Did you encounter any leap year bugs today?
#46Python. cls = , data_string = 'Feb 29 04:55:03.687' format = '%b %d %H:%M:%S.%f' E ValueError: day is out of range for month
Interesting... I suppose that is because there is no year? What year does it default to? Can you show your exact line of code?
Re: Ask HN: Did you encounter any leap year bugs today?
#47One cleanup script broke because Python doesn’t have a clean way to subtract a year, and if you do now.replace(year=now.year-1), you get a ValueError when now is 2/29. It’s easy enough to address. There are various StackOverflow posts on such things. Here is one: https://stackoverflow.com/questions/54394327/using-datetime-...
It's not that python doesn't have a clean way to subtract a year, it's that "subtract a year" is imprecise. There's a clean way to subtract 365 days, and there's a clean way to set the year one year earlier. But if you're doing the second thing, is python supposed to silently change to March 1 when you change the year from a leap day? There's no way around handling edge cases.
APy should just figure out what I would have wanted to happen
Re: Ask HN: Did you encounter any leap year bugs today?
#48I can understand getting the years 2000 (leap), 2100 (not leap), 2200 (not leap), and 2300 (not leap) wrong. But getting the year 2024 wrong is, disappointing, to put it diplomatically.
Re: Ask HN: Did you encounter any leap year bugs today?
#49Python. cls = , data_string = 'Feb 29 04:55:03.687' format = '%b %d %H:%M:%S.%f' E ValueError: day is out of range for month
That doesn’t seem incorrect; given that no year is specified, it seems like it’s evaluating the constraint in the context of an implicit default year. (1970? 0CE?)
The confusing part, to me, is that Python would consider the above string to be parsed into a date in the first place, given that it has no year.