Overcomming Date calculations when dealing with DST for UTC+01

[Hebelub]

Problem: When handling dates during Daylight Saving Time (DST), subtracting or adding days sometimes shifts the time by one hour too much or little, causing the formatted date to show the wrong day (usually a day earlier than the intended).

Question: Is there a way to convert dates by one day from any format without caring about hours and which would work for any time zone? Our website need to be able to handle any date format but should always add or subtract exactly one day.

Reproduce problem: You need to put the computer to (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna in the Date & time settings of your computer for the conversion to be a problem for dates around the last Sunday in march. These last Sundays of march is when these countries change DST time and the days only contain 23 hours instead of 24.

Context: I receive dates from the backend in yyyy-MM-dd format as strings. The received dates are off by one day, so I have to subtract a day when using them in the frontend. Before sending data to the backend I, I have to add the day back. However, during the conversion, the day is sometimes incorrectly adjusted due to timezone issues, especially around DST changes.

Here is a simplified version of my date handling logic:

import { subDays, addDays, parse } from 'date-fns';
import { formatInTimeZone } from 'date-fns-tz';

function transformAPIData(dateStringFromBackend: string) {
  return formatInTimeZone(
    subDays(new Date(dateStringFromBackend), 1), 
    'UTC', 
    'yyyy-MM-dd'
  );
}

function prepareDateForAPI(dateStringFromFrontend: string, format: string) {
  return formatInTimeZone(
    addDays(parse(dateStringFromFrontend, format, new Date()), 1),
    "UTC",
    "yyyy-MM-dd"
  );
}

Issue: When converting the date back to one day ahead, the transformation sometimes doesn’t occur properly, but is missing one hour to transform correctly, around DST transitions. Instead of just adding or subtracting a day, it may be off by one hour, leading to the date before the conversion when removing the time from the date.

[Pettersen3008]

@Hebelub I think this question is appropriate for the Q&A section.

[Hebelub]

I forgot to select that! Thank you Sander! ;)

[Hebelub]

It would be good to know of a more elegant solution than my current workaround. Here is my workaround:

• Add 24 hours (or more) instead of adding one day. (Since a day could be 23 hours)
• When I subtract, I subtract less than a day. (Since a day could be 25 hours)

These fixes works to compensate for the lost and gained hour because hours is ignored when formatting only the date and not the time to a string. (So as long as you add a few hours to the date before any date-only parsing, it should do the trick since hours will be ignored anyways)

There is also another related problem where I did a dirty trick:

• In some cases in my code I need the to do other addDays/subDays calculations to the date and I need to check for equality with another Date object. In these rare cases it will be off by an hour and thereby not equal. My current workaround here is to see if the dates differ by less then a few hours instead of strict equality since I only care about the date without the hours anyways.