Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Did you encounter any leap year bugs today?
524 points by sjr1 9 months ago | hide | past | favorite | 481 comments
After a frantic scramble this morning, our billing team has finished patching a bug which erroneously was charging our monthly subscribers for an extra day.

All test suites are passing now, and SRE has scheduled a postmortem after the QA confirms the fix in 2028.




Heard from a friend in China: the age calculation portion of the app to schedule a marriage certificate had a bug where they subtracted 22 (legal minimum age) from the year, which resulted in 2002-02-29 which doesn't exist. The app intends to compare this against the user's birth date. The error handling code assumes all errors are from the comparison. The app then rejected all marriage certificate appointments by complaining that the users are too young to marry legally.


Haha, that would be quite the appropriate place to put one of those "Please wait and try again" error messages.


"look, today the math just doesn't work out, try tomorrow"


This is often the result of consulting an astrologer in Asia for a marriage date, to be fair.


Maybe some people trying to get away with buying anniversary gifts every 4 years


How do leap day birthdays get handled in general? How is the right age iterated every year?


Relevant question for driving, voting, marrying, drinking. I'd assume just the date is compared.

If you are born on 29th, on future 28th you are considered "too young", regardless whether a 29th exists or not. On future March 1st you are "old enough" again regardless.

If a 29th exists you are old enough already on that date. Drinking beer in Germany at 16, I guess in some countries at 20 could be relevant cases. For the more common minimum age of 18 for many things, the limit is reached always on March, 1st because a 29th cannot exist.


Both Feb 28 and Mar 1 are commonly used to celebrate birthdays.

AFAIK there is no firm convention. Feb is more natural ("My birthday is in February"), Mar is more logical (the 60th days of the year).


Is March more logical? Feb 29 + 1 year = Feb 28.


You're begging the question. [1]

"Feb 29 + 1 year" is verbatim restatement.

---

You can say Feb 29 + 365 days = Feb 28. (And Feb 29 + 730 days = Feb 27.)

---

EDIT:

Note that in the context of birthdays, people use "calendar years," not "unit of time which is ~1 revolution around the sun."

Birthdays aren't celebrated every X million seconds after the moment of birth.

They are celebrated the same day each calendar year -- notwithstanding the fuzzy concept of "same day" for incongruent calendar years. There's no singuar right answer, but that is the core question: "what is the same day next (calendar) year?"

[1] https://en.wikipedia.org/wiki/Begging_the_question


> Feb 29 + 365 days = Feb 28.

Correct.

> And Feb 29 + 730 days = Feb 27

Incorrect. It's Feb 28 again. In a normal, non-leap year, if you add 365 days then you get back to the same date.


Sorry, typo I meant that Feb 28 + 730 days = Feb 27 (sometimes)


> what is the same day next (calendar) year?"

When I wrote "+ 1 year" I meant year to represent 365 or 365.25 days, not "the same day next year.":

  >>> from datetime import date, timedelta
  >>> year = timedelta(days=365.25)
  >>> date(2024, 2, 29) + year
  datetime.date(2025, 2, 28)
You may have interpreted it as begging the question, but it was not my intent—though I admit my formulation was ambiguous.

> Note that in the context of birthdays, people use "calendar years," not "unit of time which is ~1 revolution around the sun."

You've never heard someone say they've celebrated another trip around the Sun? I literally have a photo from 2007 of my daughter in Montessori celebrating her birthday by holding a globe and walking around a candle representing the Sun. I think most people probably don't really think about whether it's a calendar year or astronomical year because for most people, they are usually equivalent and it doesn't matter.

But that's all beside the point. All I meant to point out is that I disagree that March is more logical. I don't think logic points us to one month or the other. You may feel March is more logical, but I don't accept your priors, so for me March is not more logical than February.


> Birthdays aren't celebrated every X million seconds after the moment of birth.

As a surprise for a friend of mine, I threw him a gigasecond party on the day he turned 1000 million seconds old. Yes he was surprised, and a good time was had by all.


Many people say: Happy turn around the sun! and 365 is not the length of a year is the length of some years so, who knows... I'm against time zones and pro 28 days months and a couple of free days :D


By this logic, all birthdays would slowly drift as leap years pass.


Take DOB + n * 365.25 and then pick whatever day that falls in? That way it shouldn’t drift overall. Though, I guess it would imply that what day of the year people celebrate on, would be off by one day on leap years compared to what it is on other years?


This formula doesn't consider how we sometimes skip leap years, and sometimes have leap seconds, so it's vastly imprecise.


So make it more precise. DOB + n * 365.2421.


365.2425


365.2421 is more correct.

Nasa explains:

365 +0.25 - 0.01 + 0.0025 - 0.00025 = 365.24225

https://pumas.nasa.gov/examples/how-many-days-are-year


>Omitting a leap year every 4000 years

Wait, is this right? omitting every 100 and adding every 400 should be enough.

EDIT: the 4000-year rule is just a proposal for now. So 365.2425 is correct.


None of us will live long enough to see the 4000-year rule become a problem. I don't even expect to be around for the next 100-year rule.


Feb 28 is definitely too early, you haven't lived a whole year yet since your birthday. So March 1 it is. It's not your birthday but you can celebrate having made it another year.


Well 'year' can mean two different things though: 'calendar year' or 'solar year'.

Your calendar year birthday would be March 1 since one full calendar year has elapsed.

But Feb 28 is the nearest day to one full solar year, assuming you were born before about 6pm local time on Feb 29.

Two-day long birthday it is! :)


Think of it this way: if Feb 29 didn't exist that year, it would have been March 1.

If we're being scientific I guess all of us should move our birthday up by 1 day on leap years, but that seems annoying and not sure anyone really cares enough to.


No we should move our birthday celebration up by 6 hours every year. But that would be only relevant if we were celebrating at the exact hour of our birth.


We already don't move them for timezones. I was born at 3am but in France, when I'm in the US I don't celebrate the day before.


I asked JavaScript:

    const { format } = Intl.DateTimeFormat("en-UK", { month: "short", day: "numeric" });

    const date = new Date(2024, 1, 29);
    console.log(format(date));
    // 29 Feb

    date.setYear(2025);
    console.log(format(date));
    // 1 Mar

    const year = 1000 * 60 * 60 * 24 * 365.2425;
    console.log(format(new Date(2024, 1, 29).getTime() + year));
    // 28 Feb
I guess both are logical by some definition of logic.


I can agree with that.


Similar to the recent standup maths video where the town did it's art installation incorrectly - the fence post problem / off by one.

https://youtu.be/FAdmpAZTH_M?si=r_INH_C5j9mbpJSh


What’s the significance of 365? Each Earth year has just a smidge under 365.25 days.


365 days is what people commonly think of as a year. So if you're born Feb 29th and celebrate your birthday one year later (whether you call that 365 or 365.25), you land on Feb 28th. Then again, folks born between Jan 1 and Feb 28th of a leap year celebrate their birthdays 366 days later by calendar days.

Anyway, I'm not sure there's any more or less logical date to use and Feb 29th babies seem to choose both about equally:

> “I love when people ask me, ‘Do you celebrate on Feb. 28 or March 1?’” said Raenell Dawn, a co-founder of Honor Society of Leap Year Day Babies. “I get to tell them, ‘Both, because I can.’ But I’m a February baby; I was not born in March.” An informal poll of the society’s members showed about a 50-50 split between the two dates, said Ms. Dawn, who is celebrating her “Sweeter 16” by turning 64 this year.

https://www.nytimes.com/2024/02/28/style/leap-year-explained...


Celebrating on the 28th makes no sense. That is when you celebrate your Birthday Eve every year so your birthday is the next day, whatever that is.


You can make the same argument that March 1st makes no sense, as that is the day of your birthday hangover, the day after whenever your birthday is.


But 1 day is still 24 hours.

If you want to celebrate your birthday at the moment earth reaches the same spot around the sun as when you were born, then we’d all have the same issue - we’d have to celebrate it 6 hours later every year, reseting every 4 years.

February 29 is very much a new day… which simply doesn’t exist on non-leap years.


Sadly, I can say from experience the American draft does not count the number of birthdays celebrated to figure out if you're eligible to serve.


You got drafted when you were five?


More like 4… since you can go to vietnam at 17. You're thinking of the age to drink a beer.


Can't get drafted at 17. I don't know if you can go or not.


Raffaele Minichiello volunteered at 17.

https://it.wikipedia.org/wiki/Raffaele_Minichiello


Volunteering is the opposite of getting drafted


The most common approach I’ve seen is to alias them to Mar 1st.


so … many bullets were dodged today


Opinionated devs are the best devs.

Tell us about your last marriage?, lol


It's a leap year miracle!


This is why you use a datetime library.


No, but some of our software writes data to rotating directories named after the date, and while doing some manual debugging on a test system, it started failing to create these directories the first time it rotated on Feb 29 UTC. Turns out it just happened to run out of disk space at that time, but I had myself convinced that it was a leap year bug for over an hour. :)


LOL, a good example of correlation does not equal causation.


It's not. There was no correlation at hand here - this was just a coincidence


I would think it's an edge case of correlation, but still correlation (100% of the time it has had this error, it was on a leap day, 0% of the time it was not)


It might appear as a correlation due to sampling error, but the two variables have no dependence with each other. There is no correlation with it being February 29 and the bug that was described.


I think that's exactly what OP is trying to say when they say 'correlation, not causation'. There is no causal link between 29th February and the bug, but they happened at the same time (were correlated, i.e. had the relationship that they happened at the same time).

This is a fairly typical informal usage of the word correlation in my experience, and while it might not be _technically correct_ (I don't know, I'm not an expert), it's an often enough used idiom.


"Correlation does not equal causation" is a very important and pertinent concept in statistics, and I think we should aim to actually understand the concept instead of just trying to warp the meaning of the words to fit the example

The bug simply was not "a good example of correlation does not equal causation" as any statistician would use the phrase. That's my only point. OP is free to type whatever words he wants into the comment box and press send


anecdote is the singular of date, a correlate is a coincidence.


I have a friend who was born on Feb 29, and in Quebec your driver's license fees must be paid on or before your birthday or your license is effectively revoked (It's a convenient reminder). He was on his way to pay them on the 29th and got pulled over for having an expired license... after some awkward common confusion with the police they came to the conclusion that the license bureau moves your "reminder" birthday up by 1 day when the actual day is on Feb 29, instead of back to March 1st, so they don't miss out on 3 years of license payments for leap year birthday citizens.

The cop had never encountered this before (1/1460 chance of occurring * the odds of being pulled over on that day)

I don't think they ever patched this, so watch out if you're a leap day license fee procrastinator in Quebec!


Wouldn't the drivers license have the expiration date printed on it?


It's not the license expiration date is just the annual date that you need to pay your license renewal fees on.


What if the expiration date doesn't exist? Does the license just never expire? Wouldn't that be funny?


I mean, they could have paid it any day before then, right?

I would have just gone on the 28th and be done with it.


Let me tell you about this human trait called procrastination.... actually I just have to do something first


Pay By = Wait Until


Sure...if you knew about this bug in the system.


If you are born on a Feb 29th, you should definitely get used to take this kind of precautions.

(Like I do when entering my last name that is legally spelled with an "é": I still get mojibake in 2024)


We 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...


Blows my mind that people consider using ChatGPT for serious applications. I mean it's fine as a code autocorrect/autocomplete tool as in GitHub copilot. But it should not replace the code itself. You encounter a bug in the code, you fix it, you never encounter it again. But ChatGPT will repeat the same mistake sooner or later. That's not how we should engineer solution for critical problems.


As long as you add the "AI" keyword to the product/app/company and sell to people that don't understand how unreliable it is, you're good.

Let me rephrase that: you can profit from it. Even if it's not good.


If you sandbox your connection to openAI correctly, then you can get the benefit of a llm without making your application look silly at the same time. Identifying the correct places in your business to use it is tricky, but imo it certainly makes sense in a lot of specific areas. Just not a catch all that can run your business for you


It's great for prototyping and creating outlines/rough drafts or for creating rough summaries - you can build this into some features to help your customers speed up writing lots of text


If the cost-savings is worth it compared to the problems...

I mean, that's how we do it with humans. It's quite a common occurrence to keep a part of a business process human because automating it would we too expense due to edge cases.

Humans make mistakes and are expensive, but are also flexible and usually smartish. ChatGPT makes mistakes and is usually dumbish, but is also flexible and cheap.

Engineering is about picking the right trade-offs in your solution.


>I mean, that's how we do it with humans. It's quite a common occurrence to keep a part of a business process human because automating it would we too expense due to edge cases.

Which part of the human do people keep? The head? Arms? ;)

#ParsingAmbiguityError


> ChatGPT makes mistakes and is usually dumbish, but is also flexible and cheap.

People wouldn't mind it if the keyword `dumbish` has been all along there.


Wired: LLM are practically AGI

Tired: ChatGPT thinks February 29th isn't a valid date.


My favorite prompt: asking "How many e's are there in the word egregious". Always says three (ChatGPT 3.5, 4, 4 turbo). When you ask it which three, it realizes its mistake and apologizes (or sometimes tells you where they are that is completely wrong). Looks like it just outputs gibberish for these things.


ChatGPT is specifically bad at these kinds of tasks because of tokenization. If you plug your query into https://platform.openai.com/tokenizer, you can see that"egregious" is a single token, so the LLM doesn't actually see any "e" characters -- to answer your question it would have had to learn a fact about how the word was spelled from it's training data, and I imagine texts explicitly talking about how words are spelled are not very common.

Good explanation here if this still doesn't make sense: https://twitter.com/npew/status/1525900849888866307, or check out Andrej Karpathy's latest video if you have 2 hours for a deep dive: https://www.youtube.com/watch?v=zduSFxRajkE

IMO questions about spelling or number sense are pretty tired as gotchas, because they are all basically just artifacts of this implementation detail. There are other language models available that don't have this issue. BTW this is also the reason DALL-E etc suck at generating text in images.


> If you plug your query into https://platform.openai.com/tokenizer, you can see that"egregious" is a single token

That says it's 3 tokens.


It doesn’t even matter how many tokens there is, because LLMs are completely ignorant about how their input is structured. They don’t see letters or syllables cause they have no “eyes”. The closest analogy with a human is that vocal-ish concepts just emerge in their mind without any visual representation. They can only “recall” how many “e”s are there, but cannot look and count.


>They can only “recall” how many “e”s are there, but cannot look and count.

Like a blind person?


My initial analogy was already weak, so I guess there's no point in extending it. They key fact here is that tokens are inputs to what essentially is an overgrown matrix multiplication routine. Everything "AI" happens few levels of scientific abstractions higher, and is semantically disconnected from the "moving parts".


Pre-cogs, I knew it.


" egregious" (with a leading space) is the single token. Most lower case word tokens start with a space.


The number of tokens depends on context; if you just entered 'egregious' it will have broken it into three tokens, but with the whole query it's one.


Why three tokens, not one?


without the leading space, it is not common enough as a word to have become a token in its own right. Like the vast majority of lowercase words, in OpenAIs tokenizer you need to start " egregious" with a space character for the single token.


Chatgpt could say “I don’t know”


It’s always gibberish, it’s just really good at guessing.

I forgot what exactly it was I was doing. We were trying to get it to generate word lists of words ending with x or maybe it was starting with. For a marketing PoC and it made up oceans of words that not only didn’t start/end with x but mostly didn’t include x at all.

Isn’t this also why it can pass CS exams and job interviews better than like 95% of us, but then can’t help you solve the most simple business process in the world. Because nobody has asked that question two billion times on its training data.


But also it doesn't see characters. It sees tokens. The only way it would be reliably able to solve it is if it had a lookup table of token to characters. Which it likely doesn't.

You couldn't do it either unless you learned the exact matchings of all tokens to all characters in that token and their positions if you were given tokens as an input. You would have learned the meaning of the token, but not what the exact characters it represents.


Even if it sees tokens, I don't think it's an impossible task. Certainly an advanced enough LLM should be able to decipher token meanings, to know that a word is made up of the individual character tokens regardless of how the full word is tokenized. Maybe something gpt5 can do (or there's some real technical limitation which I don't understand)


> to know that a word is made up of the individual character tokens

A token is the smallest unit, it's not made of further tokens. It maps to a number.


I think what of is getting at is that given

{the:1, t: 2, h:3, e:4}

There should be somewhere in the corpus, "the is spelled t h e" that this system can use to pull this out. We can ask gpt to spell out individual words in NATO phonetic and see how it does.


> There should be somewhere in the corpus, "the is spelled t h e" that this system can use to pull this out.

Such an approach would require an enormous table, containing all written words, including first and last names, and would still fail for made up words.

A more tractable approach would be to give it the map between the individual tokens and their letter component, but then you have the problem that this matching depends on the specific encoding used by the model (it varies between models). You could give it to the model during fine-tuning though.


The best approach would be to instruct it to under the hood call a function for such asks and hide the fact that it called a function.


He's saying the LLM will figure out how many letters are in each token.


They cannot “figure” it, they could learn it but for that it would need to be in it's training data (which isn't because nobody is writing down the actual pairing in every byte pair encoding in plain text. Also the LLM has no clue about what encoding it uses unless you tell it somehow in the fine-tuning process or the prompt.)


It's as feasible as telling how many chars in html lead to this comment by looking at a screenshot. LLM doesn't see characters, tokens, numbers or its own activations. LLM is a "set of rules" component in a chinese room scenario. Anything an operator of that room does is lower-level.

GGP's idea suggests that an LLM, allegedly as a whole-room, receives something like: "hey, look at these tokens: <tokens>, please infer the continuation". This puts it into a nested-room's-operator position, which (1) it is not, (2) there's no nested room.


The point is though that this is definitely not a task to evaluate an LLMs intelligence with. It's kind of like laughing at Einstein when he wouldn't be able to decipher hieroglyphs in any language without previous training for those hieroglyphs. Could Einstein potentially learn those hieroglyphs? Sure. But is it the best use of his time - or memory space?


I just asked it with Gemini; at first, it got it right. Then I asked if it was sure and it apologised and said 3 is the correct answer. When asked what are the 3 "e"s, it says:

> The three "e"s in "egregious" are: > > 1. The first "e" is located in the first syllable, between the "g" and the "g". > 2. The second "e" is located in the second syllable, following the "r". > 3. The third "e" is located in the third syllable, following the "i" and before the last "o".


That's because it's trained on 2021 data. No February 29 back then!


For the record, both ChatGPT-4 and Gemini Ultra affirmed that it's a valid date. Gemini reasoned through it and GPT-4 ran python code to make sure 2024 was divisible by 4.


Interesting... But that isn't exactly true! Centuries that are not divisible by 4 don't count!


I've yet to come across a form of 100 that isn't divisible by 4... since 25 usually still exists!

But I do remember there being some weird niche rules about which years are or aren't leap years, so I'm guessing your comment is basically right just wrongly worded?


The rule is that leap years are the ones divisible by 4. Unless it’s also divisible by 100. Unless unless it’s divisible by 400.

So 2000 was leap, but 2100, 2200, and 2300 won’t be, but 2400 will be.


Ahh, so it's centuries that aren't divisible by 400 rather than that aren't divisible by 4, that makes more sense!

Thanks for answering


It's centuries that aren't divisible by 4. It isn't years that aren't divisible by 4.


The GP formulated it in a somewhat unclear way. "Centuries" divisible by 4 probably meant "years" divisible by 400.

So, 19th century (1900 is the last year) isn't divisible by 4 (19/4 is not integer), which is the same as saying that 1900 isn't divisible by 400.

This is the main reform of the Gregorian calendar - leap days aren't introduced on xy00 years which aren't divisible by 400. This corrects the length of a year to 365.2425 days, which is fairly close to the real value of 364.2422 days.

The original Julian calendar had year of 365.25 days, which aggregated an error of more than ten days over the centuries.


Did it also check if 2024 is divisible by 100 but not 400?


But akshually neither does my uncle Ned


Saw the same via the API with gpt-4-0125-preview. IOW, even gpt-4 thinks 2024 is not a leap year.


That's weird, I don't get that with gpt-4

https://chat.openai.com/share/336b1c4b-53b7-4d56-ac68-e3c868...


Given the probabilistic nature of LLMs, you likely need to run an experiment several times to see the various different results it can produce.


ChatGPT thinks today is March 1. Go ahead and ask it what today’s date is.


> No, 2024 is not a leap year. Leap years are years divisible by 4, except for years that are divisible by 100 unless they are also divisible by 400. Therefore, the next leap year will be 2024.


As the proud new owner of a leap day baby, I find this to be extra hilarious


I was at the hospital and heard two babies being born. I love that music.


Congratulations!


Congratulations!

Big savings on parties and cake!


Apparently it reads 2024 as two different numbers: 202 and 4


thats better then Mistral... it "thinks" it is March 15th 2023

"The current date is March 15, 2023. However, please note that as a large language model, my knowledge is based on the data I was trained on, which is up to 2021. Therefore, I cannot provide real-time information or updates on current events or dates. I recommend checking a reliable source such as a calendar or a trusted news website for the most accurate and up-to-date information."


It is March 1 in many places


It's UTC. Ask it what day was yesterday.


As of 10 PM US/Eastern, ChatGPT 3.5 answers as follows for me:

> You: what is today's date?

> ChatGPT: Today's date is February 29, 2024. Please note that February 29 occurs only in leap years. If you have any more questions or if there's anything else I can help you with, feel free to ask!


openai actually in their platform for billing, etc shows that its actually march 1 as well.


Yes.

> During the morning on Thursday, no ICA store in Sweden could accept card payments. Instead, you had to use cash, Swish or pay via their app.

> The reason behind the problem was an internal problem in the payment systems at ICA as a result of an extra day in February, leap day.

ICA being the biggest grocery store chain in Sweden


And people in sweden look at me weird when I say I keep some cash around.

At least it wasn't 3 days like when Coop's provider got hacked. They also handle our pay checks at work… makes me feel so safe :D


Particularly odd since the Swedish calendar has had a lot of leap-day shenanigans, including a one-time Feb 30th.

https://en.wikipedia.org/wiki/List_of_non-standard_dates#Feb...


The other way around! Today a few services that don't congratulate me on my birthday (on non-leap years) did. I was born on February 29th.


How often do you encounter challenges related to your birthday? Meaning, not just on the day of Feb 29, but any day of the year when you're trying to select your birth date or something like that. Do you ever find forms where the date is missing or the backend wont accept it?


Occasionally, but less often than one could imagine! About a dozen times in my life.

Whenever February 29 wasn’t present as an option, the frontend was at fault, so I could set the right <input> value in the inspector as a workaround.

Other times February 29 was present as an option, only to be saved as February 28. Never March 1, which I’d say would be more coherent.


If it makes you feel better.... On February 29, 2008 I was working on a system as a government contractor. Part of it was outsourced to a sub-contractor who decided to write their own date/time library because how hard could that be (which I only learned about later)? For some reason NOTHING would work right that day. Took me longer than I'd care to admit of staring at the logs to realize that some started with March 1 2008....

edit: also happy birthday!


Definitely not any more coherent on a leap year! That remark only applied to dates stored without a year, as in “February 29” rather than “February 29, 2008”.

Thank you..!


> more coherent

depends on what you're trying to organize by. maybe 'birth month' is an important signifier.


Here’s why:

* I was N years old on February 28th this year

* I will be N+1 years old on March 1st this year

Therefore:

* I was N-1 years old on February 28th last year

* I was N years old on March 1st last year

Perhaps the month is February and the non-leap year date is March 1st...


Happy birthday to you! It’s a special day and We don’t get this chance to say this often. Enjoy your day


Thank you :3


Were you born on the day after Feb 28 or the day before Mar 1? ;)


Yes


Happy birthday!


Thank you ^_~


https://www.askamanager.org/2018/01/i-paid-for-fake-referenc...

You're not alone!


Stay, yanateres, stay! They have no legal claim! No shadow of a shame will fall upon thy name: stay, yanateres, stay!


...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.


I’d say March 1! February 28 might be too early.


365 days ago was March 1, 2023


In 365 days, it will be February 28, 2025

Which is more important, the past or the future?


This year has 366 days, or at least it does after Feb 29.


At midnight in-between 28th February and 1st March.


This one is rather specific, but a game rhythm based Final Fantasy game called Theatrhythm Final Bar Line is simply not allowing people to play today because it has an internal system that awards prizes for specific days and they didn't handle the case of what to do when it's on a leap day. You can boot it up but can't actually play the game as a result.

Not working on the game or anything but found it moderately amusing as someone who owns the game!


Yeah, this one was odd. I also ran into it.

https://gamerant.com/theatrhythm-final-fantasy-bar-line-not-...


That's why they had to release FF7R2 today. It was planned all along /s


All street lamps in Paris turned off at midnight :)

https://www.leparisien.fr/paris-75/paris-pourquoi-les-rues-d...


The street lights use some sort of timer that's tracking dates? Don't they typically just use light sensors to know when to turn on? It seems to me that'd be a simpler solution and also provide light during solar eclipses, thick storms, etc.


First, these systems generally predate invention of semiconductor light sensors.

Second, how much light you need is proportional to human activity, not only to darkness. At deep night artificial lighting should be minimal to save energy, minimise disturbance to nature and people's sleep, while during early morning when kids go to schools it should be maximal.

Third, you need a central control over street lights anyway because you need to implement blackouts during wartime.


> Third, you need a central control over street lights anyway because you need to implement blackouts during wartime.

You heard of switches? Hell in our country with mandated rolling blackouts to prevent failure of the national electrical grid some sucker gets paid to drive around town every 2-3hours and flip a switch. Unrelated one municipality is failing to follow the mandate because they cannot afford said suckers overtime pay...

I also strongly believe well lit streets at all times are important, its better to try to limit the lights' bleed than it is to have darkness. One human killed or otherwise injured (rape/assault) due to bad lighting should be enough to say this is a bad idea.


Why should we pick a simple solution like that? Is it the 90s or what? Only a complete clown would pick anything other than a network of zigbee relays controlled by an unmaintained node.js app written by an out-of-business contractor, pulling in sunrise/sunset data from an external API and syncing its local time via a homegrown NTP alternative.

I mean look at electric cars.


Finally, night time photography without the street light pollution.


Oh! The street lamps on my campus didn't come on tonight when it got dark—it didn't occur to me then but this could totally be why.


Improved nighting is an awesome gift. I'm jealous.


The City Without Lights


Yes, I have a bot that posts daily San Francisco weather records to Mastodon. It did not post as scheduled today. This is because I am looking at all the high temperatures, low temperatures, and precipitation on today's date from 1875 (about as far back as there are digitized weather records I can work with) to the present. Since there was no such date as February 29, 1875 it is throwing an error.


I just dont get the “daily” weather records thing. Meteorologists talk about them constantly but theyre completely meaningless right? who cares what this particular day of the year highs were? its just noise! at least do it on a weekly resolution instead but even that seems so noisy itd be meaningless.

sorry, this has nothing to do with you, just a pet peeve.


People like them because they happen more often. "This is the hottest February 29th on record!" but it's not the hottest February 28th or March 1st.

Compare that to something more mathematically rigorous: "Today is warmer than 98.72% of days between February 25th and March 5th". Nobody's going to click that link.


Your words read like you're disagreeing,

but the idea seems like it's agreeing.


As weather conditions are roughly cyclical with a period of a year, this doesn't strike me as a particularly unusual thing for a weatherperson to mention in passing.

Though you're correct in that year-over-year weather changes and daily maxima lack the significance of long-term climate trends.


One thing I have learned from HN is that datetime issues are hard, prolific, programming language agnostic, and not to trust myself to get the logic right. (The same applies to floats.)


Another thing programmers should know and fix is that most of it is self-inflicted. When there’s no easy way to add a day, people add 86400000 and stumble upon a leap second. When time is not needed, they use fixed hours and fail at timezones. And so on. Most date libraries provide mostly trivial and at the same time low-level use-cases, so people do all the stupid math with what essentially is an irregularly-based number.


just like you don't roll your own crypto, you don't roll your own date libraries.


Takes me less to launch some coin fork than getting even a single date time api correctly.


The API is correct, you just called it at the wrong time


Facts!


Datetime and phonenumbers are two subjects that are notorious for how complex they are despite seemingly simple everyday concepts


From "Falsehoods Programmers believes in" series:

https://news.ycombinator.com/item?id=4128208


I haven't had too many true hair-pulling moments in my life as a programmer, but the majority of them were because of datetime issues.

My brain just doesn't get the concept I guess, I always struggle a lot whenever I need to touch anything that does anything with dates/time


Surprised no one else mentioned the Cloudflare billing issue today. I got incorrectly invoiced yesterday and the file was named cloudflare-invoice-1970-01-01.

https://www.cloudflarestatus.com/


I know I'm late to the party, but I have a Python script that creates a security.txt for one of my own project, and it sets the "Expires" date to one year in the future.

Old code:

expires = datetime.datetime.now(tz)

expires = expires.replace(year=expires.year + 1)

It broke yesterday, throws an exception ("ValueError: day is out of range for month"). It's kinda obvious that it does.

Fixed version code:

expires = datetime.datetime.now(tz) + datetime.timedelta(days=365)

expires = expires.isoformat(timespec="seconds")

Now we're just going 365 days into the future. Of course, this has a slightly different meaning and outcome, we are not always ending up on the "same date next year". But in this use case it doesn't really matter.


In .NET there is an AddYears function that deals with all of this, and even gives you Feb 29 if the date is valid, otherwise Feb 28: https://learn.microsoft.com/en-us/dotnet/api/system.datetime...


There's the same in python, but if you wanna write shitty code you can always get around it


Yup relativedelta https://dateutil.readthedocs.io/en/stable/relativedelta.html


Is it just me or does .NET have the most sane standard library for dealing with dates? Until you get into timezones that is


Didn't see it mentioned here but cloudflare sent me an invoice today and the attached PDF was titled cloudflare-invoice-1970-01-01.pdf :)


Was the content of the PDF correct? Or did it also have some strange dates in it?


yeah everything inside the pdf was correct


oh no wonder they had a billing outage.

https://www.cloudflarestatus.com/


Their 32 bit time_t ran out sooner than expected!


It's scary how much code out there is less than 4 years old, and even scarier how much of it is because someone decided to somehow rewrite it unnecessarily and thus introduce this bug. I don't even want to know how many people think the code they wrote will be in use for more than 4 years.


On the other end of the scale, the code base I worked on today has seen at least 7 separate leap days in production. Last week a manager asked if we expected any issues with the leap day, and we all just kind of laughed (and politely said no).


I 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.


Those are harder to get wrong, since leap year bugs are almost always from consumers of dates. To screw up a not-a-leap-year-year you'd need to produce a bogus February 29 on a real March 1. Date producers tend to understand how the calendar works better than that.


That's putting it very diplomatically indeed.


There was one in the Phoenix Framework (Elixir) about issuing certificates with an invalid end date: https://github.com/phoenixframework/phoenix/issues/5737

Interestingly, Azure had this bug some years ago too leading to an outage. https://azure.microsoft.com/en-us/blog/summary-of-windows-az...


Not today but several years ago while lending a hand on a project that was wildly overdue and the guys needed all the help they could get. Disclosure: it was not in software that was in production yet(otherwise you would have likely heard and been affected by it by now I suspect). The software's purpose was dealing with commercial airlines - routes, connections and all that. The travelling salesman problem basically. The software was meant to replace an antique system which no one knew how to maintain since in 2020 it was still running on mainframes and written in fortran. There were specifications on how the system worked but there was no one who could even read the code. Anyhow, the way dates were stored, read and calculated was absolutely insane. I can't recall what the exact deal was, but each date was represented with either 4 or 5 bytes with some really awkward algorithm to make it into something meaningful. With a bunch of additional patches surrounding Y2K.

Unfortunately it was a lot more subtle than getting March 1-st instead of Feb 29-th. Each date was calculated with a dynamic offset depending on the month and year. So during leap years, everything was fine until the 14-th of May at 01:00 UTC. The second the clock hit, 14-th of May at 01:01, all hell broke loose incrementally as time want on until the end of each year. The weird string representation for Nov 1-st was being calculated as January 3-rd for instance. But as soon as the clock hit January 1-st, everything went back to normal. It took 6 people 2 days to figure it out. As you might expect, this was not mentioned anywhere in the documentation.

I'm not sure what has happened ever since, but if the system made it into production and you didn't get stuck in an airport... You're welcome lol


The Casio F-91W doesn’t account for the year, it showed today’s date as Thursday, March 1st.


That's more of a design decision than a bug. It's intentional to make the product cheaper. The manual does mention it.


Wow, you're right.

>Calendar system: Auto-calendar set at 28 days for February [0]

[0] https://support.casio.com/en/manual/009/qw593.pdf


I noticed this too and clicked this thread wondering if it would show up! Still an awesome watch.


Same with my colleagues most recent top model Samsung Galaxy Watch :]


Odd, mine is showing the right date.


Are you sure? My F91W doesn't even ask for year in settings. How would have it known it is a leap year or not.

Some other models (not F91W) does track year.


I was responding to the claim about the Samsung Watch not showing the right date, I unfortunately have never owned the older kinds of "smartwatches" :)


Are they using a third party watch face? My Galaxy Watch 4 has no issues.


I have a custom watch face on my GW4 and it's showing the 29th


OK on my Watch4 Classic FWIW.


I just looked at my watch and indeed the date is wrong. Thanks!


Thank you so much for the reminder, that would have screwed me up today :)


Here's a blog post that is tracking issues:

https://codeofmatt.com/list-of-2024-leap-day-bugs/


Yes, Hesai LiDAR [1] bug is grounding cars.

[1] https://pandaily.com/hesai-technology-addresses-lidar-produc...


Fascinating - why does a LiDAR involve the date?


LiDARs and other sensors typically need to be time-synchronized with the rest of the robotic system. I wouldn't be surprised if the bug is related to that.


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


Unix time has discrepancies whenever leap seconds occur (several times in my career aquiring geophysical data).

If you're measuring | controlling objects in the physical world (cars, rockets, etc) then you should not use unix time - those glitches will happen and instantaneous computations will go kooky.

https://en.wikipedia.org/wiki/Unix_time#Leap_seconds


But so does resolving to a date. I don't see how resolving to a date which cares about leap days fixes any of that.

You should use a monotonic clock with an arbitrary starting point anyway, unless you need some kind of synchronization between devices, but you probably wouldn't use unixtime there anyway.


> But so does resolving to a date. I don't see how resolving to a date which cares about leap days fixes any of that.

So why bring it up then?

> You should use a monotonic clock with an arbitrary starting point anyway

Sure. We started doing that more than 50 years ago now when broad area geophysical surveying started off.

> unless you need some kind of synchronization between devices,

Can't see the problem - there are ways of syncing base station records against aircraft | boat | vehicle records in post processing .. all the stations, fixed or mobile, use a monotonic epoch based record structure that hold channel data and any sync marks that are broadcast by whatever means - raw GPS time serves well enough for a grain of 1.5 seconds, other marks can be used as required.


I think I'd have used time-since-power-on; your infotainment system could take an RTC offset to get that to human dates.


"should"


Remember, always use a library for cryptography, payments, and date calculations.


Yup. I use the datetime module in Python and didn’t need to do anything extra.


For JavaScript, it’s `date-fns` for me


wrong! always roll your own crypto!


Get a load of this guy.


We have a rails 6 app, and there's a test that essentially expects time_ago_in_words(1.year.from_now) to return "about 1 year" (as part of a user facing message). The test failed. I thought it's a flaky test but i was able to reproduce it locally. Turns out executing that code on a leap day returns "almost 1 year" instead. Can test it in rails console if you are interested:

  irb(main):001:0> include ActionView::Helpers::DateHelper
  => Object
  irb(main):002:0> distance_of_time_in_words(Date.new(2025, 2, 28), Date.new(2024, 2, 29))
  => "almost 1 year"
  irb(main):003:0> distance_of_time_in_words(Date.new(2025, 3, 1), Date.new(2024, 2, 29))
  => "about 1 year"
  irb(main):004:0> distance_of_time_in_words(Date.new(2025, 2, 28), Date.new(2024, 2, 28))
  => "about 1 year"


> distance_of_time_in_words(Date.new(2025, 2, 28), Date.new(2024, 2, 28))

Curiously, this is also not quite a year, even though the days and months are the same.


It’s probably comparing the number of days between the dates with the number of days in a year, which would usually work.


Source is a lot more complicated than i thought it will be: https://github.com/rails/rails/blob/v6.1.7.7/actionview/lib/...


Why this is not a global holiday? Let's all come together and agree to do nothing on this bonus day. Calendar Problems solved.


Even those "24/7/365" people technically agree, today is a day off.


We should get it off work. We aren't getting paid for the extra day of work right?


No power, no hospitals, no internet, no phones, no care homes etc.


Depends, some are paid by the hour.


Exactly. Off the books for everyone.


EA Games were crashing today and they announced that the solution is to set the date to March 1st: https://twitter.com/eahelp/status/1763192739322085598


My sister is staying in a hotel and all the keycards stopped working.


What happens in a situation like this? Does the staff issue physical keys? Do the doors even have manual locks? Do the staff walk every body to their room?


About a year ago I stayed in a hotel and the door lock started misbehaving one morning while I was at breakfast. Went to the front desk, got a new card, went back to the room and discovered it still didn't work. After doing that two more times, someone was sent up to the room with a mysterious, palm-sized device with a USB cable hanging off it, which they plugged into a well hidden USB port on the bottom of the lock. The device performed some black magic, and after about 30 seconds a light on the lock changed colour from orange to red and it started functioning correctly again.


This also happened on Leap Day 2020 with Onity locks used in Crown Plaza Hotels. See https://i.imgur.com/GI5A3jW.png. I wonder if it's the same issue never fixed? Can you share with us the hotel chain and/or the lock manufacturer? Thanks.


> A number of New Zealand petrol pumps stopped working on Thursday due to a "leap year glitch" in payment software, fuel stations and the payment service provider said.

https://www.reuters.com/world/asia-pacific/leap-year-glitch-...


Related ongoing thread:

Self-pay gas station pumps break across NZ as software can't handle Leap Day - https://news.ycombinator.com/item?id=39553755 - Feb 2024 (31 comments)


I'm sure it's more complicated than "we didn't think about leap years", but it certainly sounds pretty amateurish.

Old programmer rant: In my day, we fixed the Y2K bug - we went to the future and back several times a day!


In your day people weren't doing everything with string ops in JavaScript.


Oh, the progress we've made!


It does sound amateurish eh? I do most of my business logic inside Microsoft SQL Server Stored Procedure, and MS SQL just takes care of date pretty well.

But then, come to think of it, you don't need to use SQL to have good date logic. C# and Java both have excellent date handing libraries. I don't know about C++, but I'd be surprised if there was not a modern date library for C++, so I am of the opinion there should be no excuses for software not to work on the 29th of Feb.


> but I'd be surprised if there was not a modern date library for C++

The standard library now includes <chrono>. AFAIK: It was mostly written by Howard Hinnant. He now has more date/time libs that expand upon <chrono>: https://github.com/HowardHinnant/date


Yes if you're writing your own date/time routines, dealing with dates as seconds since epoch, or anything like that you're going to get burned.

Use date handling functions and libraries that have been developed by people who know how to do it and have been battle tested.


I certainly did. There is a batch process to cull old records. It checks for customers who do not have a date of death recorded but are > 130 years old, as it assumes that we weren't informed of their death.

It takes 130 years from the current date and uses that in an SQL statement to compares it to the date of birth. DB2 doesn't like 1894-02-29.

Apparently it happens every 4 years, but no-one can be bothered to fix it.


A simple fix would be to change it to a multiple of 4 (e.g. 124 years). Then it would fail every 100 years.


128! It was right there!


2000 was a leap year so it would not fail in 2100. But it would indeed fail in 2200/2300/2400 as 2100/2200/2300 are not leap years.


But then it's someone else's problem.


Most likely nobody's problem, really.


And it's still enough to include Jeanne Calment's supposed age.


Unless 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.


So you're paying them to not fix a bug in their system, am I reading that right?


I wouldn't expect google to mess this up but then again someone probably calculated value produced vs project cost and tossed this one at the bottom of the pile 10 times already. 66/100k people (0.066%, close to the definition for a rare disease) would be born on 29th of feb on a uniform distribution, probably minus another 5% or so because february is in many places the least likely month to be born into. And out of those people how many actually put in their real birthday? Still odd to mess up a subtraction though.


Google is now outsourcing development to low cost countries. They dont care about quality much


> 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

I know you're on iPhone which limits your choices but I'll mention this here anyway, could be useful to someone. Firefox has an addon[1] to fix that. It's very simple and basically just disables the events that tells the page you've switched tabs, and for Youtube sends a random keyboard event every N seconds.

I've used it for years and it's great. I can't imagine paying Google of all companies for a feature like that.

[1]: https://addons.mozilla.org/en-US/firefox/addon/video-backgro...


That should be a top comment here as it is most annoying and prevalent bug of all presented in this thread.


Fascinating. I presume you were born on Feb 29 of 2004 or earlier. What did the system do when you tried to purchase? I'm curious how the error manifested. Thanks.


My monthly bus passes for both February and March did not work in Dallas today. The driver was aware of the issue and just waved me in.


Our Sophos anti-virus at work blocked access to every website this morning because of the leap year, had to disable the web filtering to get us back up and running.


Yeah, so many "untrusted website" screenshots in the office chat. Half a productive day for staff in Australia


Does anyone affected have a copy of one of the affected certificates? I'd be interested in seeing more detail on what went wrong.

The most likely thing to me would be that it attempted to issue a 1-year-long certificate, but naively produced a date of Feb 29, 2025.

Dates in certificates are encoded as `YYMMDDhhmmssZ` so it would certainly be possible to produce a certificate with an invalid date.


Python.

    cls = <class 'datetime.datetime'>, data_string = 'Feb 29 04:55:03.687' format = '%b %d %H:%M:%S.%f'
    E       ValueError: day is out of range for month


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!


It wasn't. https://learn.microsoft.com/sl-SI/office/troubleshoot/excel/...


Crikey - more helpful to me is the page linked from there - https://learn.microsoft.com/sl-SI/office/troubleshoot/excel/...

> However, there is still a small error that must be accounted for. To eliminate this error, the Gregorian calendar stipulates that a year that is evenly divisible by 100 (for example, 1900) is a leap year only if it is also evenly divisible by 400.

> For this reason, the following years are not leap years:

> 1700, 1800, 1900, 2100, 2200, 2300, 2500, 2600

I had no idea!


"We establish that a bissextile [366th day] shall be inserted every four years (as with the present custom), except in centennial years. So the years 1700, 1800, and 1900 will not be leap years. Assuredly, the year 2000 will have an extra day in it." -- Greg XIII, 1582


1900 was not a leap year... It's 0 mod 4, yes, but it's 0 mod 100 and not 0 mod 400


Yep, thanks, I just wasn't aware of the latter rule at all. Time to re-read Falsehoods perhaps!


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.


Interesting... I suppose that is because there is no year? What year does it default to? Can you show your exact line of code?


confirmed. and interesting/unexpected! this breaks:

datetime.strptime('Feb 29 13:37:06.942', '%b %d %H:%M:%S.%f')

edit: added code example. import datetime from datetime first obvi


That's because you didn't specify a year.


Yes, an amusing one: the Android app for the Berlin public transport, on the 29th, listed the results with the date of the previous day (28th).

The funny thing is that the list is prefaced by a banner saying that this is a known bug, and the results actually refer to the 29th.

Interesting way to workaround a bug :)


The app was probably designed to be able to show an emergency banner if ever needed. Easier to change that message than fix a complicated API.


I think this is it here, yes? https://twitter.com/abhyudaypratap_/status/17632771389442543...


Yes :)


Spotify Artist which is app for managing as name states your artist profile should allow you to run promo campaigns but they need to be set till the end of the previous month. Well. 29 February according to spotify is not a valid February date.

I know it's somehow an edge case but it's one which appears every four years so I dont understand how it could be missed by such a big company.


And if someone wanted to point out that I shouldn't let things to last moment.

He would be absolutely right.


https://review.coreboot.org/c/coreboot/+/80790


Python script using datetime crashed with a "ValueError: day is out of range for month" exception.


I have some unit tests for billing and subscription code for my company that started breaking in CI today due to the leap day: https://github.com/sagemathinc/cocalc/commit/8575029c2b76787...


We got a bunch of close-dated yogurt the other day.

Several were best by 2-27, 2-28, 3-01, and 3-02, but none by 2-29.


> none by 2-29

traditionally known as the "Angel's Share" :P


One of the largest food store chains in Sweden had their entire card payment go down because someone forgot to handle leap years!


Wikipedia says they are "the second largest retail company in the Nordic countries[citation needed]". Pretty big company anyway and embarrassing for them. Would love to learn more about what the bug was, but I guess they will never say.

https://en.wikipedia.org/wiki/ICA_AB


Is that intended as a correction? It’s a different claim, as far as I can tell, and the data I could find points to ICA in fact being the largest supermarket chain in Sweden by turnover.

https://www.esmmagazine.com/retail/top-5-supermarket-retail-...


No disagreement, just additional information.


Tbh I was just too lazy to find its place in the rankings. It sure is a big business anyway


This isn't even one of the weird years!

Is this why we can't have nice things?


One 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.


Which type of year? Sidereal or solar? Did you account for axial precession?


To be a bit blunt, these questions are entirely irrelevant, since you know the answer as well as I do: the calendar year, the one Western law and international business uses uniformly. It's very clever of you to mention that other concepts of the year exist. Kind of. Would have been more clever if you'd realized that they aren't germane, any more than the Islamic, Jewish, Indian, or Chinese years are.


> There's a clean way to subtract 365 days

What is it? Does it attempt to return a datetime that's the same time as the input but 365 calendar days earlier (ignoring leap seconds? compensating for time zone changes?), or does it subtract 31536000 seconds from the current datetime? Because those aren't necessarily the same and it's ambiguous which one you mean by "subtract 365 days"


APy should just figure out what I would have wanted to happen


What is your definition of "subtracting a year"? Seems like that's a relatively ambiguous operation without more specification.


Can you think of any situation where subtracting a year from today's date is ambiguous when today isn't, well, today?


Yes - on any day, subtracting a year might mean subtracting the average length of a year (which is a bit more than 365 days), or wanting the same day and month number in the previous calendar year, or wanting the same semantic difference ("last Monday of the month in January"), to name a few possible meanings.


Moving bank/festive holidays, first Monday of the year(, first work day of the year not Monday if that's NYD and bank holiday), lunar occasions.

'subtract a year' is imprecise and has many meanings, if what you want is 'same day, same month, previous year' then say that and do that, that's conceptually `date.year -= 1` not `date -= 1 year`, and will have this bug.


You could subtract 365.25 days, but then you're left with a new problem: just because you can amortize a leap day over four years doesn't mean that you get an extra 6 hours each year.


And as I just learnt elsewhere in this thread, it would actually be three four-hundredths less than that anyway, i.e. 365.2425, since only one in four centenaries is a leap year.


Worth a mention... Falsehoods Programmers Believe About Time: https://news.ycombinator.com/item?id=4128208


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.


While that's true, I'm sharing scar tissue here not hypotheticals.

There's often someone out there who interprets such things as a 3 month, or 1 year retention policy and that it means they're entitled to look at the entire range whenever they want.


Plenty of thought has gone into this. Look at what database date functions do when you ask it to subtract 1 year. I will agree that there is not one answer.


It is ambiguous, but one part that's pretty unambiguous is that the result should be a date, not a crash.


> now.replace(year=now.year-1)

Yeah but this is bad code. Python certainly does have a "clean" way to subtract a year, you subtract a datetime.timedelta object.


timedelta doesn't take "years" as a parameter, for the reasons others have listed here. It's ambiguous what subtracting by a year means, and there's no real sensible default either.


relativedelta will do it:

  from dateutil.relativedelta import relativedelta
  one_year = relativedelta(years=1)


I get it if you don't want to bring in another dependency, but Arrow has a lot of nice utility methods: https://arrow.readthedocs.io/en/latest/guide.html#replace-sh...


which is why you should use arrow


Okay I am having really odd undefined behavior in Python in UART communications that were working just fine yesterday... My boss joked it could be a leap year thing but at this point it wouldn't surprise me. Switch over to using Rust and no issues at all


EA Sports WRC has a bug that can be fixed by setting the date to March 1st. https://twitter.com/EAHelp/status/1763192739322085598


Yes, in T-Mobile billing, I tried to set up automatic payments on the 26th, but the system both told me that this was impossible (because it was "less than 2 days from the end of the month") and then accepted it, because why wouldn't it.


Yes - I triple-checked the calendar to verify my suspicion this February might have 29 days. The result was always negative - it seemed 28. Then February the 29th actually came. A bug apparently occurred in my mind.


I can also never remember if "leap year" means 29 days or 28 days, and which one is normal. I probably checked that twelve times this week. And I was mildly surprised when I noticed that March 1 was Friday and not Thursday...


As a child I somehow always forgot and thought 27 was normal, and then one year the calendar in our kitchen showed 29 days. that was kinda confusing.


Found one on iMessage! Wished former coworker a happy birthday, and it said, "Siri found a birthday: March 1". Though when I pressed update, it correctly marked it as the 29th.


Many years ago I visited Laos. We crossed the border at a rather remote and little-used border crossing.

Laos issues 30-day tourist visas on arrival. We arrived on February first and I have a Laotian visa valid until February 30th, 2011.

Not a leap year bug but a February bug. Ended up being inconsequential, but still makes for a fun story.


You have a picture?


Available only for a few days: https://www.dropbox.com/scl/fi/dnu5nnyzi7lf0bu3n0ait/laos-vi...


It's even handwritten wow


Last night around 8:00 PM I noticed the time on my Linux laptop was wrong. I tried to reset it manually and got a "Cannot set current time" error. Closed the dialog and a minute or two later the time reset to the correct value. I shrugged it off as something random.

Then today I get home from work, un-suspend that same laptop and the time and date are both wrong now. It has it as around 10pm last night. Turn off auto updates and turn that back on, and nothing happens. Wait 4 or 5 minutes, nothing happens. So I finally decided to reboot, which does indeed clear things up. Only then did I remember that today is Feb 29th and make the connection that this might be related to the leap year.

Can't say for 100% certain that it was, but it would be one hell of a coincidence otherwise.


If you have date/time problems that are unrelated to leap years, there's a 1/~1,461 chance of it happening on a Feb 29th.

Given how many devs/techies/linux users/(and even non-techy users of tech) will encounter random time or date related bugs and problems every year, it would be surprising if there weren't a few people getting that coincidence every time a Feb 29th rolls round (or put another way, it seems likely that there's more than one person in the world having a similar "no idea what caused that" date/time bug every day of the year, including this one). So maybe related, but I wouldn't call it one hell of a coincidence if it's not related.


And the doubly sad thing is, I'll almost certainly never really know. But such is the way of life.


Stupid question. How do these bugs happen?

If you just take the naive approach and calculate everything as unix timestamp deltas, “yesterday” in human terms will still be 86400 seconds ago. No difference leap day or not.

If you use a date library with fancy “subtract one day” functions, it should also be handled automatically. Just like you don’t have to care that March has 31 days and April 30? No difference if leap day or not.

Someone must have spent a lot of effort to manually create date logic, hard coding the number of days in a month or something?

Only other edge case is if someone takes a 2024-02-29 timestamp and modify the year part, without using date library to do so. That should be rare, only use case is a yearly report. That’s not something that should take down the whole billing system.


> Only other edge case is if someone takes a 2024-02-29 timestamp and modify the year part, without using date library to do so.

Date library does not help here, for example, both Python and Java's date library [0][1] have only "days" in their timedelta/Duration constructor. Month and year are ambiguous. What would you do if you want someone's birthday this year? The most obvious way:

    birthday: datetime.date
    birthday_this_year = birthday.replace(year=datetime.date.today().year)
is just broken. The second line throws.

[0] https://docs.python.org/3/library/datetime.html#datetime.tim...

[1] https://docs.oracle.com/javase/8/docs/api/java/time/Duration...


The Java library actually supports this case.

It may not have the convenient "years" method directly, but you can add an arbitrary unit of time quite easily

Example with duration:

    Duration.of(1, ChronoUnit.YEARS)
Example with datetime:

    today.plus(2, ChronoUnit.YEARS)
It even supports decades, centuries, eras and half days :-)

For those curious about how it handles leap years:

    var leapDay = LocalDate.of(2024, 2, 29)
    leapDay.plus(1, ChronoUnit.YEARS);
   
    // ==> 2025-02-28

    var lastYear = LocalDate.of(2023, 3, 1);
    lastYear.plus(1, ChronoUnit.YEARS);

    // ==> 2024-03-01

    var lastFeb = LocalDate.of(2023, 2, 28);
    lastFeb.plus(1, ChronoUnit.YEARS);

    // ==> 2024-02-28

    var firstFeb = LocalDate.of(2024, 2, 1);
    leapDay.with(TemporalAdjusters.lastDayOfMonth());

    // ==> 2024-02-29


Thanks! It does this according to doc:

    This method adds the specified amount to the years field in three steps:
      * Add the input years to the year field
      * Check if the resulting date would be invalid
      * Adjust the day-of-month to the last valid day if necessary
TIL. I didn't know that Java had a builtin calendar (instead of datetime) library.


> Only other edge case is if someone takes a 2024-02-29 timestamp and modify the year part, without using date library to do so. That should be rare, only use case is a yearly report.

Another use case: you create a pair of cryptographic certificates with a validity period of 1 year. The other side rejects the certificate because of an invalid date. This happened 12 years ago to Azure: https://azure.microsoft.com/en-us/blog/summary-of-windows-az...


I've seen many date-related bugs similar to these and in very few cases it's as simple as "one developer was incompetent and did something stupid". Incompetence may be part of the problem, but in the background there are often data sources or services that provide the data in non-standard or unpredictable ways as well as specific business requirements that complicate the process.


One case I can imagine is if the authors of law/rules that the code tries to implement were trying to be clever and defined the specific way this edge case needs to be handled. In such situation developer is likely forced to do some manual logic instead of the straight forward whatever happens when offsetting timestamp by 365 days using time library.


Gusto paycheck didn't come in until a lot later than usual... thought this might have been my last day on the job for a little bit, didn't help that my manager and I's one on one was my first meeting of the day heh.


My Casio F-91W thought it was March the first and got me confused for a moment. But other than that I saw no other bugs.


I wear Xiaomi's Amazfit Pro 3R. Digital. Wrist band. Hung at midnight of 29th Feb today. Did a bunch of factory reset but didn't recover. And then recovered at the morning of 1st of March.

Date is relatively simple.

    days_in_month(year, month) :
      if(month==2) return days_in_feb(year)
      //all other months have constant number of days, always.

    days_in_feb(year,month) :
      if(!(year % 400)) return 29;
      if(!(year % 100)) return 28;
      if(!(year % 4)) return 29; 
      return 28;
And you are done for all Gregorian years.


your function returns 29 days for every year not divisible by 400


!(x % y) is the same as (x % y == 0), which means the remainder is zero, so x is divisible by y.

So it returns 29 if divisible by 400, 28 if divisible by 100, etc.


Oops, you are absolutely correct!


Payroll software at work had a one-off planned maintenance day today, presumably to avoid worrying about any bugs.


lucky it didn't fall on a payday eh?


Today is a payday for us, worked great!


I did.

Unit tests were broken in the CI pipeline because of a leap year. The problem was validating the number of days in a year, but dismissing a leap year. The code assumed the number of days in a year was 365.


Same thing for us


Yeah! Our friends got married yesterday, and now they have until 2028.02.29 to legally change their names.


I had to renew my vehicle registration this month. You usually have until the last day of the month to get it done. But this year the state of North Carolina said that was the 28th, not the 29th.


I 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 the 29th-31st of other months? Or do they happen on March 1?


> 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?


I do have plenty of monthly renewals, just not annual ones. I actually went to see if I'd had any annual renewals on the Feb 29, 2020, and it looks like I had just one, but they lapsed due to credit card failure. Fingers crossed that we get a signup today and can have a renewal on our next Leap day!


A coworking space I signed a contract for starting on March 1st sent me an email on 02-28 telling me my membership starts tomorrow and welcome on board.


I am gald that in excel, deleting a day from March 1st automatically gives Feb 29 or 28 depending on the year in formula. Before that, I struggled a lot to find last day of month by tracking if its a leap year or not, and keeping an array of months & number of days. Now I simply add 1 to month, and from resulting daye I subtract 1 day. The Date value of that gives me 31 or 30 or 29 or 28.


One of our reporting systems closed month end reporting yesterday. Made everyone mad until they realized things can still be changed today.


Today is the start of the new tax year here in South Africa and my brother wanted to draw the last years worth of transactions from a local financial institution to be able declare his tax.

Setting the date range from 2023-03-01 to 2024-02-29 was not permitted as it says the date range must be within 12 months. Of course a general limit of 12 months is a bit of a WTF too.


Not today, but two years ago. Our ocean buoys started calling in from March 2nd on February 28th.

I describe the bug as part of my presentation at the Embedded Online Conference back then: https://youtu.be/RDUQ0w-5Ws4?si=P6gGDhZC3-3KPKq9&t=787


I have a small hobby project that scrapes concerts on various venues websites.

Many of the websites don't write out which the year the concert takes place, so in python I will: try the current year and see if the date has already passed, and in that case I try the next year.

Of course feb 29th is an issue in this case, so some of my scrapers modules crashed.


Using Google Gemini:

Prompt:

> Is 1200-02-29 a valid date?

Answer:

> Python

>import datetime > >try: > datetime.datetime(year=1200, month=2, day=29) > print("Valid date") >except ValueError: > print("Invalid date") > >Output: > >Valid date > >Yes, 1200-02-29 is a valid date. > >According to the Gregorian calendar, leap years occur every four years except for years that are divisible by 100 but not divisible by 400. The year 1200 is divisible by 400, and therefore it is a leap year and February 29th exists in that year.

Wrong: the Gregorian calendar didn't yet exist in year 1200, so its rules don't apply for that year.


Now that you mention it, the payment system was not working in a ski resort restaurant in Switzerland this noon.

They had to switch to cash.


The national law enforcement background check portal was down today, I wonder if the leap day had anything to do with it.


My Casio F91W I assumed would know that year YYYY is leap, and would show 29th as Date. No, it showed 1 as in March (it doesn't show months). I had to manually set it back to 28th so that tomorrow it shows correct date.

To be fair, it doesn't ask for year anywhere in settings. It simply doesn't know what year it is.


Had a pair of tests break CI.

At least one of them was the test, code it was testing did its job fine but test could not cope with February 29th. Obviously the test is broken in two different ways: it fails on Feb 29 and more importantly tests the behaviour on $current-date so only tests edge cases on the day of.

Other I didn’t follow.


Yes, 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.


I had a unit tests for a Java LocalDate that was being increased by one year. It checked whether the month and day were the same, and failed because the current day (29) didn't equal the year-hence one (28). I changed it to check that the difference between the days was less than two.


Previously your unit test was broken one day every four ish years. Now it's broken every day :)


A unit test shouldn’t even be depending on the current date in the first place


This is a hard-earned lesson, but it's true.

Instead of doing

  def do_something_with_date():
      now = datetime.now()
      return now - timedelta(days=2)
you should do

  def do_something_with_date(now):
      return now - timedelta(days=2)
and explicitly pass in edge-case dates into the `now` param in your unit tests.

Alternatively, if you're using Python, use the freezegun library to fix the current time in tests: https://github.com/spulec/freezegun


Right, fixed such test today


Our 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.


Until tomorrow when your system is now off by a day for the next 365 days.


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.


My suite failed this morning on an obscure test of a function that converts between ages and dates of birth. Took me ten minutes of head scratching before I realised it was Feb 29th.

’’’ + if time.Now().Month() == time.February && time.Now().Day() == 29 { + t.SkipNow() + } ’’’

Fixed.


We had a bug on the 1st of this month. Some billing code liked to invoice on the last day of the month and failed to account for this month having an extra day. Interesting it happened as soon as the "leap month" started. Easily fixed though.


Billing. It always has to be the billing. For a list of all other edge cases, you have: https://github.com/kdeldycke/awesome-falsehood#readme


A fiber cable was cut so we had no internet for the morning, probably not leap year related.


Breaking News: The legendary report from 2017 finally cracked yesterday:

queryset.filter(user__last_login__gte=today.replace(year=today.year - 1)).count()

Meanwhile, in the betting world, someone actually placed a bet on the day of the week for February 29, 2020.


Just hope the King of Sweden doesn't make another February 30. https://www.timeanddate.com/date/february-30.html


Every time I go to timeanddate.com I feel like I see a link to the Leap Day page (https://www.timeanddate.com/date/leap-day.html) that shows the meme-infamous boyfriend-checking-out-another-girl couple, except she's proposing to him! Obviously this happened earlier that day since they're wearing the same outfits, and I can't help but feel bad for her knowing what's coming but unable to warn of the impending train wreck.


Let's just be happy that it isn't still the day after February 24 that becomes the inserted leap day. https://www.isof.se/lar-dig-mer/kunskapsbanker/lar-dig-mer-o...


We should just do what we do for time changes and do feb 28 over again.


Or do leap hours and have a 25 hour clock for a day


I'll take a February 30 if it means every other month is 30 days too, and we just get the extra days as universal, extended winter holiday where no one can legally be required to work because there is no December 31st or January minus-fourth.


Uniting time zones in Kazakhstan today looks like more of a headache, at least to me.


Yup, all our rolling-year calculations failed because you can't have 29 Feb 2023!


These ones are the worst because you'd think they'd be so obvious at time of implementation. Maybe it's just me, I do a lot of comparisons and things like this always are top of mind for me.


Ran into a bug where some code was taking an hour long interval and subtracting 1 year from the start and end times. But the time library handled subtracting a year from Feb 29 as converting it to Feb 28th of the previous year, at the same time. So on-call got alerted because a job failed when an exception was thrown because the start time was after the end time. Fortunately, other than the alert, there wasn't any negative impact. Although, I think if this isn't addressed it may cause issues next year when it includes a bigger interval of time than expected on March 1st.


We had test failing that had to be skipped and worked out in the background.


My (cheap, digital) watch thought it was 1st of March.

Funnily enough when I went to change the date the watch allowed me to select Feb 29th. I wondered if it had supports for leap year and it was off by exactly one year but that's unlikely as it didn't seem like cycling through the dates changed it to 29. Most likely it allows selecting manually the 29th but then skips from 28th to 1st of March every year.

All my billing / calendar booking is outsourced to Paddle / Stripe / third parties so no other issues in my products!


My wife’s company had an issue with this today. A couple hours before I read this she mentioned it to me and I just assumed human error was the cause. Then I read this and it clicked. Crazy shit.


Well it is human error after all. By the programmers. Oe those who invented the complicated calendar


Microsoft is off by one this year, with their 365 line of products


The mcdonalds order waiting thing malfunctioned, displayed de52hg04 instead of 088 and I had to wait a lot longer for my order since it flew under the radar for a while until I spoke to them :)


https://twitter.com/EAHelp/status/1763192739322085598


Yes, not a software bug but kind of on point https://imgur.com/a/xMKFn3e


My daily crontab at just after midnight UTC did not run yesterday. I wrote it off as a server hiccup, but now you got me thinking it might be related to leap years…


Can't you just backdate some servers to confirm the fix?


Not directly related to leap year, but a couple weeks ago I set up a script for testing notification behavior that used libfaketime to simulate runs at different times.

I guess this might be less-trivial if you've got a distributed multi-service architecture and perhaps also depend on APIs that aren't under your control in the first place.


Set up a backdated timeserver and use that to sync time


That's generally risky to do nowadays because of things like TLS certificate expiration.


In a few hours you'll be able to backdate to "yesterday", with very low chances of hitting cert expiry issues (but I wouldn't be surprised if OP's issue involves components outside of their control or ability to test end-to-end)


I should have written something along the lines of "validity date ranges" instead of expiration: you're much more likely to run into problems where you run into a certificate that was issued in the future relative to when you think is now.


I work in scheduling software and had no issues today surprisingly. But we have hundreds of end to end tests that cover daylight savings as well as leap years.


Saw my bank book every auto-transfers, like utilities, rents etc.. booked for 28th to be again booked on 29th, i.e. twins appeared. But then those disappeared after the mid-day. Not sure if those were caught and fixed by anti-fraud system as double-charging or was just strange bugs somewhere, but happy that they disappeared, as it would be weird to explain to my landlord about why I decided to pay double rent.


Which bank?


Wonder if orgs are getting ready for 2038 like they did for Y2K. Only 14 years or so away.

https://en.m.wikipedia.org/wiki/Year_2038_problem

https://en.m.wikipedia.org/wiki/Year_2000_problem


Kind of... Spent a while debugging an issue where the client was convinced he could not schedule new appointments in the system on the 29th.

It turned out he had set another setting incorrectly which was causing the appointment never to be valid.

But the rarity of the date let me wonder in the wrong direction for a while...


Years ago i ran a script to fill a db table with entries for each day by incrementing a timestamp by 86400. It skipped the 29th of this year


“Anyone who thinks programming dates and times is easy probably hasn’t done much of it.” - Peter van der Linden, Expert C Programming


Why are there so many stories about leap year bugs?


Because programmers take shortcuts. Its easier to type x - 365 than to import Calendar and then date(x) - timedelta(1 year).


And standard library design errors also.

Properly designed date/time API invented relatively recently.

System.DateTime (.NET) - 2002 | System.DateTimeOffset - 2005

Joda time (JVM) - 2005 | java.time - 2014

Temporal (JavaScript) - still experimental


It’s strange to me, it hasn’t been than long since a leap year and I don’t remember as many last time.


It’s the first go-around for the jr devs who went to school during the pandemic :)


I was doing an online check in with the national Argentinian airline. My wife’s and I data was already in the system from the previous checkin. When we were about to confirm we noticed that both of our birthdates where off by one day earlier. I can’t confirm it was related to the leap year but I also cant find another explanation.


I 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


Just AFTER reading about Casio watches in this thread I looked at mine. Sure it displays the date as March 1.


Maybe? My paycheck direct deposit didn't show up until almost 7am. Normally it hits right at midnight.


Yeah, I have a Python script for personal use, and briefly could not figure out why it was crashing. The reason : I was using

class datetime.date(year, month, day)

which was attempting to generate "today, one year ago" by reusing the current month and day, but replacing the year with year-1.


Colombia's largest airline (Avianca) printed today's tickets with the 1st of March as a date


One of the most common QA test cases when it comes to testing date and time sensitive applications.


I have an old client who called and is having issues with their registration/calendar system.

When the page loads it looks for events two years in the future, which as you might guess based on the context of this thread, simply increments the current date's year by two.


Yes. We had some test failures. Test setup was to create records for today, yesterday, last week and last year and make sure they are generated correctly. Well last year's date didn't match today's. Easy fix but it was hilarious.


My new pixel 8 needed an update on the 28th. It told me the update would happen at 2am on the 1st March and duly waited an extra day to perform it. I'm assuming standard Android update policy is not now to wait an extra day.


Yes. Be mindful about if your industrial firmware really needs to know the datetime..


Yesterday in New Zealand (29 Feb) couldn't fill up my car at two petrol stations - both had self-service terminals that were down because of leap year. Ended up having to go inside at a station at pay the old fashioned way.


I have a daily reminder set up in Apple’s Reminders app and it didn’t trigger today.


I'd suggest not waiting 4 years to publish a postmortem, if you're serious


Using Google docs it usually autofills the date for me but today it couldn’t as I typed the date the calendar widget came up. No Feb 29! I typed 2024-02- waited and it didn’t show up. 2024- then autofilled 2024-03-01


my m1 macbook air, which has been powered down for a few months, would not automatically get the date from the time server, which broke some stuff.

set it manually, no problems, hopefully will be able to turn it back on tomorrow


Hi! In my internet banking, I needed to schedule one invoice for the last working day of march, 28th, Friday. System responded that this is Sunday so invoice could not be scheduled.


I don't know if it was a Leap year bug but after midnight my wife's phone still said Feb 29th even though it should have switched over to March 30th at 00:01


I unsubscribed from Netflix and was supposed to have it till the end of februar. But yesterday the 29. there was already no more access ..

Quite trivial, but still a bit ridiculous.


> and SRE has scheduled a postmortem after the QA confirms the fix in 2028.

:)


Not a single one, either in the code at work or anywhere else.


I 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.


I bought a couple guardian bikes a couple days ago. Their website said they would arrive today, February 1. I assumed it was some kind of weird leap day issue.


Do what George Washington and Abraham Lincoln did and just latch to a nearby Monday. That's an instant three day weekend.


Our credit card invoice system shifted all invoices that were due 28th to the 29th of February. Still trying to figure out what happened.


Are they monthly invoices? Most billing systems will bill monthly recurring bills that have an anniversary of 28, 29, 30, or 31 on Feb 28. Maybe your system was actually doing the right thing and putting only 29, 30, and 31 on Feb 29.


Yes! It's anniversary based. What went wrong actually was the notification part. As Feb 29 was not an expected anniversary, it didn't schedule any notification to be sent.


My "smart"watch froze at 23:59 28th Feb


Hikvision access control camera would not let anyone into the building on Feb 29. Had to get tech out to upgrade


My desktop machine did not time out overnight last night and require me to enter my password to resume wasting time this morning.


The calendar lockscreen widget on iOS reported an event that had already happened as upcoming on March 1st, pretty minor


Pandas CI broke today because of the leap day and testing for datetimes. Pretty similar story to the other Python examples.


We did but I only learned of it today! Completely broke a lot of systems until they set the day to March 1st and back


Yes, the local transport Timetables App was showing the 29.02 routes as 28.02 and they have put advice on this problem


Reading the comments here and can't believe that so much software still has these bugs. 2038 is going to be FUN.


Citi Bank's credit card "Merchant Offers" showed some offers as expiring in "-1 days".


My bank sure encountered a bug: they're APIs are returning march 30th for some records.


Unit tests failing because of scenario that offset a date by a number not divisible by 4 and compared...


My Citizen ana-digi-temp from 1985 works perfectly fine and shows Feb 29.... though it thinks it is 1996!


Probably resets every 28 years, that way it can keep track of the day of week (at least until 2100)


Sunsynk inverter seemed stuck on Feb 29 today 2 March, not sure if leap day or other cause


Found some bugs in TESTS which have been running fine for <=4 years, but failed today.


On AWS Cost and usage control panel:

> Forecasted month end costs

> There isn't enough historical data to forecast your spend


Pretty much all of the self service gas station terminals in New Zealand went down for the 29th


Hikvision access control camera would not let anyone in the building on Feb 29


Just realized. I'm absolutely flabbergasted nothing happened at my company.


I got an invalid grant - bad request from google oauth on one of 3 identical servers


EA Sports WRC.

Crashes on launch. Put the system clock forward and it works... it boggles the mind.


Llama2 models refused to acknowledge that the date was a valid date.


Yes, we had a test fail when generating `12 days ago` strings from a past date.


gpt-4-0125-preview was the output from "date" and commented that my date implementation must be broken because 2024 is not a leap year and therefore the 29th isn't a valid date... Go figure.


According to the Intranet, it was everybody's birthday yesterday.


Didn't even realize it was a leap day until I saw this post.


Fortunately no, we use Carbon in PHP and it is super solid.


My university login website now does not allow me to login


A charge from something I bought today says March 1st.


What time zone is the merchant in?


> after the QA confirms the fix in 2028.

Dang, your QA team is fast.


my home assistant integration for solar/energy monitoring did not register any data for feb 29. from midnight to midnight


Yeah, the AirBnB where I'm currently started renovating the apartment upstairs. I guess that's a bug. In the ideal life, that wouldn't have happened hahaha! :)


shopifies calendars and some ad dashboards are showing 2 days in view instead of 1 for today/yesterday


A few unit tests broke, nothing major.


Today? No. But ask me in a week.


I got paid early. Is that a bug?


probably teams had one, today it was showing me all meetings from yesterday


Uber is down in Mexico City




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: