Why does DST affect addition/subtraction?

[alex996]

I am new to Luxon coming from dayjs, which has the same behavior (allegedly, a bug). The code below produces different results when it's run in a time zone that observes DST:

// luxon.js
const { DateTime } = require("luxon")

const date = DateTime
  .fromISO("2024-06-04T10:51:36.135Z").plus({ days: 200 })
  .toJSDate().toISOString()
  //.toUTC().toISO() // same issue

console.log(date)

"luxon": "^3.4.4"

# Asia/Bangkok (Thailand does not observe DST)
$ date
Tue Jun  4 18:35:25 +07 2024

$ node luxon.js
2024-12-21T10:51:36.135Z

# America/New_York (the US observes DST)
$ date
Tue Jun  4 07:35:46 EDT 2024

$ node luxon.js
2024-12-21T11:51:36.135Z

My understanding is we're parsing an ISO 8601 date that's in UTC (ends with "Z"). So, in both cases we're operating on the same underlying date. We add 200 days. The outcome shouldn't change depending on where in the world we do the addition.

I'm sure there's a reason why this happens, unless it's a bug. Can someone please explain?

[diesieben07]

fromISO (and other parsing functions) produce a DateTime in the local time zone. Thus, when you add 200 days, it's adding 200 days in that time zone, so the addition is affected by DST (i.e. days are not always 24 hours).
If you want your DateTime in a different time zone, call setZone / toUTC on the result of fromISO.

You can also pass { zone: XXX } to fromISO, which will do this for you, but has the side-effect of also using that zone for parsing if the ISO string has no offset.

[alex996]

Thank you. Putting fromISO aside, is it intended behavior that addition/subtraction can produce different results, depending on whether DST is observed?

Ex: I changed my code to use now(). I would think that running this code at the same time in Asia/Bangkok and America/New_York would yield the same result. Logically, "now" is the same moment of time in every time zone (in JS, same number of milliseconds since the epoch), and in 200 days from now, it'll still be the same moment everywhere. How come it's instinctively true, but does not hold in code?

const { DateTime } = require("luxon")

const date = DateTime
  .now().plus({ days: 200 })
  .toJSDate().toISOString()
  // .toUTC().toISO() // same issue

console.log(date)

# Asia/Bangkok (Thailand does not observe DST)
$ date
Tue Jun  4 20:14:22 +07 2024
$ node luxon.js 
2024-12-21T13:14:25.948Z

# America/New_York (the US observes DST)
$ date
Tue Jun  4 09:14:51 EDT 2024
$ node luxon.js 
2024-12-21T14:14:53.585Z

[diesieben07]

Logically, "now" is the same moment of time in every time zone (in JS, same number of milliseconds since the epoch), and in 200 days from now, it'll still be the same moment everywhere.

This is unfortunately not true, because days are not the same length everywhere due to DST changes. In the long run obviously they are, because DST "adds" an hour once a year and "removes" an hour once a year, but DST is observed at different times in the year.

Taking your example, when you add 200 days from now, Asia/Bangkok will not have observed DST, but on 2024-11-03 at 02 am America/New_York will set the clocks back by 1 hour. As such, the "200 days" will take one hour longer to complete in America/New_York, because they turn the clocks back by one hour during those 200 days - making that hour "happen twice".

If you were to add an amount of days that includes both DST transitions for America/New_York you would get the same point in time, because one of the days will be one hour longer and one of the days will be one hour shorter.

Edit:
I realize the text above might not explain it very well. Let me give you a concrete (simpler) example:
Take 2024-11-02 at 11pm in America/New_York. If you "add a day" it'll be 2024-11-03 at 11pm, but 25 hours have passed (due to DST).

Now take 2024-11-02 at 11pm in Asia/Bangkok and "add a day". It'll be 2024-11-03 at 11pm, but 24 hours have passed. Thus "adding a day" in both time zones does not result in the same amount of time being added.

[alex996]

I think I got it. It turns out that when doing math with days, Luxon adjusts for DST. This part in the docs is key:

if you add a day to a DateTime, you should always get the same time the next day, regardless of any intervening DSTs

This means that when crossing the day when DST starts, Luxon is adding 23 hours, and when it ends, it's adding 25.

In my example, it's actually adding different durations, that's why the ISO strings don't match:

const now = DateTime.now();
const bkNow = now.setZone("Asia/Bangkok");
const nyNow = now.setZone("America/New_York");

const bkFuture = bkNow.plus({ days: 200 });
const nyFuture = nyNow.plus({ days: 200 });

console.log(bkNow.toJSDate().toISOString() === nyNow.toJSDate().toISOString()); // true
console.log(bkFuture.toJSDate().toISOString() === nyFuture.toJSDate().toISOString()); // false
console.log(nyFuture.diff(nyNow, "hours").toObject()); // { hours: 4801 }
console.log(bkFuture.diff(bkNow, "hours").toObject()); // { hours: 4800 }

Luxon doesn't adjust for DST with hours. So, to make addition idempotent, I'd need to do .plus({ hours: 200 * 24 }) instead.

I appreciate your response. I didn't get that 2024-11-03 in the US is a day that's actually 25 hours long.