All test suites are passing now, and SRE has scheduled a postmortem after the QA confirms the fix in 2028.
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).
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.
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.
Nasa explains:
365 +0.25 - 0.01 + 0.0025 - 0.00025 = 365.24225
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.
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
"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?"
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.
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.
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.
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 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.
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...
Tired: ChatGPT thinks February 29th isn't a valid date.
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.
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.
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: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.
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?
> 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".
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."
> 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!
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.
People wouldn't mind it if the keyword `dumbish` has been all along there.
Which part of the human do people keep? The head? Arms? ;)
#ParsingAmbiguityError
Let me rephrase that: you can profit from it. Even if it's not good.
https://chat.openai.com/share/336b1c4b-53b7-4d56-ac68-e3c868...
> 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.
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...
edit: also happy birthday!
Thank you..!
Which makes sense since then it is "after" your birthday.
Which is more important, the past or the future?
You're not alone!
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...
I mean look at electric cars.
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.
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.
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
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.
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
Some other models (not F91W) does track year.
>Calendar system: Auto-calendar set at 28 days for February [0]
[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.
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-...
Old programmer rant: In my day, we fixed the Y2K bug - we went to the future and back several times a day!
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.
Use date handling functions and libraries that have been developed by people who know how to do it and have been battle tested.
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
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)
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.
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.
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 hits 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...
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.
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 monthThe 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.
datetime.strptime('Feb 29 13:37:06.942', '%b %d %H:%M:%S.%f')
edit: added code example. import datetime from datetime first obvi
>>> 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)Edit: no it's not, it's absolutely correct, leap years just aren't as simple as I thought!
> 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!
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 :)
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.
He would be absolutely right.
Several were best by 2-27, 2-28, 3-01, and 3-02, but none by 2-29.
traditionally known as the "Angel's Share" :P
https://www.esmmagazine.com/retail/top-5-supermarket-retail-...
Is this why we can't have nice things?
It’s easy enough to address. There are various StackOverflow posts on such things. Here is one: https://stackoverflow.com/questions/54394327/using-datetime-...
Everything is use case dependent. Sometimes the use case is unimportant enough that mistakes are okay.
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.
'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.
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.
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"
Yeah but this is bad code. Python certainly does have a "clean" way to subtract a year, you subtract a datetime.timedelta object.
from dateutil.relativedelta import relativedelta
one_year = relativedelta(years=1)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.
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.
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.
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.
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)
[0] https://docs.python.org/3/library/datetime.html#datetime.tim...
[1] https://docs.oracle.com/javase/8/docs/api/java/time/Duration...
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)
today.plus(2, ChronoUnit.YEARS)
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 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
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...
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;
So it returns 29 if divisible by 400, 28 if divisible by 100, etc.
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.
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?
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?
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.
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
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.
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.
They had to switch to cash.
To be fair, it doesn't ask for year anywhere in settings. It simply doesn't know what year it is.
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.
Instead of doing
def do_something_with_date():
now = datetime.now()
return now - timedelta(days=2)
def do_something_with_date(now):
return now - timedelta(days=2)
Alternatively, if you're using Python, use the freezegun library to fix the current time in tests: https://github.com/spulec/freezegun
’’’ + if time.Now().Month() == time.February && time.Now().Day() == 29 { + t.SkipNow() + } ’’’
Fixed.
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.
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!
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.
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...
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
This is in code we use for scheduling
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.
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.
set it manually, no problems, hopefully will be able to turn it back on tomorrow
Quite trivial, but still a bit ridiculous.
:)
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.
> Forecasted month end costs
> There isn't enough historical data to forecast your spend
Crashes on launch. Put the system clock forward and it works... it boggles the mind.
Dang, your QA team is fast.