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.

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

"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

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.

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)

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

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.

Nasa explains:

365 +0.25 - 0.01 + 0.0025 - 0.00025 = 365.24225

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

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.

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! :)

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.

    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

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

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

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.

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

Tell us about your last marriage?, lol

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.

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

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!

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

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

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

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

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.

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

#ParsingAmbiguityError

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

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

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.

That says it's 3 tokens.

Like a blind person?

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.

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.

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

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

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.

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

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?

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

Thanks for answering

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.

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

Big savings on parties and cake!

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

> 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

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

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

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.

edit: also happy birthday!

Thank you..!

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

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

You're not alone!

Which makes sense since then it is "after" your birthday.

Which is more important, the past or the future?

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

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

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

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.

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.

I mean look at electric cars.

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

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.

but the idea seems like it's agreeing.

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

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

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

https://www.cloudflarestatus.com/

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.

https://www.cloudflarestatus.com/

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

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

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

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

Some other models (not F91W) does track year.

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

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

Telling base where, and when, you were

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

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.

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.

  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"

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

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

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)

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

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

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

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.