Inconsistent Date-Time Output in Luxon Based on System’s Current DST Status

[gabrielbull]

Describe the bug
When using Luxon to create a date-time, the resulting value differs depending on whether the current system time is before or after Daylight Saving Time (DST). Specifically, if the system date-time is before DST, the created Luxon date-time does not match the same date-time created on a system where the actual date-time is after DST.

To Reproduce
Run the following code twice, once on a system with the actual system date-time set before DST, and once after DST:

const { DateTime } = require("luxon");

console.log(
  DateTime.fromObject(
    { year: 2023, month: 11, day: 5, hour: 1, minute: 0, second: 0 },
    { zone: "America/New_York" }
  ).toJSDate()
);

Observe the date-time output differences based on whether the system date-time is currently before or after DST.

Actual vs Expected behavior
Actual behavior: The date-time output varies depending on the system’s current DST status.
Expected behavior: The date-time output should remain consistent regardless of the system’s current DST status.

Desktop (please complete the following information):

• OS: All
• Browser: All
• Luxon version: 3.5.0
• Your timezone: "America/New_York"

Additional context
This issue may lead to inconsistencies in applications relying on consistent future date-time calculations across systems with different current DST statuses.

[diesieben07]

The datetime input you have provided is ambiguous, because it exists during a DST change. First you have 1am at UTC-4, then at 2am the clocks are moved back one hour and you now have 1am again, but at UTC-5 this time.

In these ambiguous cases Luxon picks the offset that corresponds to the current time. In theory there is a mechanic to allow selecting which offset to be picked, but this is currently not exposed. It's only used for the parsing functions, when parsing a timestamp with both zone and offset specified. A pull request to expose this option would work for me, if you need it.

Luxon does provide you information about this ambiguity via DateTime#getPossibleOffsets. If you call it, you'll get both possible timestamps.