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