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

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.

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.