Fix date-handling bug when today’s date is later than the target month (opens in new tab)

Reminder to use something like the date-fns library for immutable operations on dates. The native JS date library can be painful to work on when doing operations like adding or subtracting time.

I make this bug in my taxes every now and then. Most invoices are from EU, but the few US ones have the months in wrong order, I only notice if the days exceed 12

How is 3+3+2+3+2+3+3+2+3+2+3 equal to 5?

The bug exists every time today's date is greater than the lowest total number of days in a month (28). So it's a bug for 3 days in January, (sometimes 1 day in February,) 3 days in March, 2 days in April, etc.

I had something like this for a while. It wasn't a bug per-say, it was a test flake due to dates and follow on calculations based on them. On the plus side, it prevented you from working on the weekend as the tests/PRs would always fail during that time.

I've seen somebody write this exact bug before! Hah. Like, something to the effect of

    var newDate = new Date(GetDate().Year, GetDate().Month + 1, GetDate().Day);

but with extra logic to ensure that the Month component wrapped around.

I was just browsing HN because I'm procrastinating solving a date based bug. It is literally this bug! Who said surfing HN is not productive!

...the comment! The hubris!

        // Important: Important to set these in order

Very relatedly, there's a potential similar footgun related to hours, due to the fact that dates initialized without hour default to 00:00, and that JS dates are in user's current local timezone.

It's possible then that after changing the month programmatically, the time component will jump to 23:00 due to timezone DST changes, and the date will jump back one day as well due to this (and in an unlucky case, the month will jump back as well!)

Example bug I had in 2014 when Russian timezone definitions have changed:

https://github.com/yui/yui2/pull/15

A workaround is to initialize dates with fake "midday" time component so that you avoid the day jumping back.

The fix is to change things like this:

  targetEndDate = new Date();
  targetEndDate.setFullYear( endDate.getFullYear() );
  targetEndDate.setMonth( endDate.getMonth() );
  targetEndDate.setDate( endDate.getDate() );

to

  targetEndDate = new Date();
  targetEndDate.setFullYear(
    endDate.getFullYear(),
    endDate.getMonth(),
    endDate.getDate());

That works because setFullYear has a three argument form that takes the year, month, and date avoiding the inconsistency that can arise by setting those one at a time.

But you know what else has a three argument for that take the year, month, and date? The Date constructor.

So why not fix it like this?

  targetEndDate = new Date(
    endDate.getFullYear(),
    endDate.getMonth(),
    endDate.getDate());

Using the empty constructor would initial the object with the current date and time, but they promptly overwrite those.

The Date construction also has a form that takes another Date object, so I wonder if they could have simple used:

  targetEndDate = new Date(endDate);

You should never, ever do date math naively like this. There are too many unexpected edge cases, especially between time zones or daylight savings time or leap years, but even without them: https://moment.github.io/luxon/#/math

In fact I would strongly argue you should never use the JS Date built-ins at all because they are terrible. Use a library like Luxon or date-fns. As a frontend dev, this is the most common category of bugs I've dealt with in my career, and I've spent dozens of hours fixing other people's datetime handling because of how poorly implemented the JS Date API is. It's full of minefields and gotchas.

The Temporal API is supposed to fix some issues, but that's been in development for like a decade now.

Apparently, date handling is still causing problems in 2024, as evidenced by the Newag trains' DRM.

Unlike many issues with dates, this one is purely a result of a wrong API design. It does not make sense to "set a component" of a date all by itself (unlike hours/minutes/seconds in a day), so an API that allows you to so is plain broken.

Correct API would be to set the components D,M,Y all at once and have them validated on the spot before returning a valid Date value.

Did I not look closely enough? I didn’t see any tests in the changes.

I tried to replicate the bug only to find out the months are 0-indexed (jan = 0) so the example should use `setMonth(1)`.

I must say I'd prefer getting an exception rather than a silent roll-over any day of the week – pun intended.