Remember, always use a library for cryptography, payments, and date calculations.
Ask HN: Did you encounter any leap year bugs today?
141–150 of 498 posts
Re: Ask HN: Did you encounter any leap year bugs today?
#142Re: Ask HN: Did you encounter any leap year bugs today?
#143Earlier quoted context omitted.
...it occurs to me, when should those services congratulate you? Should it be on February 28 or March 1?
According to the government, Mar 1. Anything that is based on your birthday (driver's license, drinking, signing contracts, etc) all happen on March 1 if there is no Feb 29 that year. Which makes sense since then it is "after" your birthday.
[deleted]
Re: Ask HN: Did you encounter any leap year bugs today?
#144Unless you're in your 70's, YouTube doesn't allow you to buy premium if you were born on a leap year, because their age calculation is broken, and it thinks you're under 18. Google One works fine. Support will suggest that you change the birthday on your Google account, which breaks account recovery processes that depend on you furnishing matching identity documentation. Mind-boggling.
Because nobody at YouTube has apparently ever encountered this problem, I ended up having my partner buy a family plan. As much as I hate paying so much a month for YouTube of all things, screen-off background play is a paid feature on iPhone, having one of the two accounts on your TV showing ads is absolutely infuriating and I'm not sure I fancy risking an account ban for anything they can associate with someone costing them ad revenue.
Re: Ask HN: Did you encounter any leap year bugs today?
#145Re: Ask HN: Did you encounter any leap year bugs today?
#146I just checked and realized I have zero annual Stripe renewals that have come through so far today. Not a big surprise, since most of our customers are on monthly subscriptions. I have wondered about how Stripe handles months with differing numbers of days (for monthly subs), and leap years (for annual subs). Do they accelerate renewals in short months, so that February 28 has all the renewals that normally happen on…
> Do they accelerate renewals in short months,
Yes. They bill on the last day of the month if your anchor date is past that. In fact most billing systems do, which is why Feb 28th is the best day to load test billing systems. Because you'll get four days worth of renewals on one day.
Interesting that you don't have renewals today, I wonder if they did them yesterday and have a bug?
Re: Ask HN: Did you encounter any leap year bugs today?
#147We 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…
Wired: LLM are practically AGI
Tired: ChatGPT thinks February 29th isn't a valid date.
Re: Ask HN: Did you encounter any leap year bugs today?
#148One 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-...
What is your definition of "subtracting a year"? Seems like that's a relatively ambiguous operation without more specification.
It is ambiguous, but one part that's pretty unambiguous is that the result should be a date, not a crash.
Re: Ask HN: Did you encounter any leap year bugs today?
#149One 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.
This has been a factor in contract law for longer than computers have existed. "Subtract a year" or "Add a year" aren't really imprecise, it's just that there are two ways you can interpret it: 365 days, or 12 months. When adding, you get the same result: end of February, the 28th. Subtracting, you get one of March 1st for 365 days and February 28th for 12 months.
Most jurisdictions use the 12 month standard, fwiw. I believe that's the ISO ruling as well, but I wasn't able to confirm that.
Re: Ask HN: Did you encounter any leap year bugs today?
#150Earlier quoted context omitted.
Fascinating - why does a LiDAR involve the date?
For the survalence records Telling base where, and when, you were
Shouldn't that just be a unix timestamp or something? You'd think resolving that to a date time could be done in the UI instead of in the business logic