Hacker News Reader

Comment by Too | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com