How does Luxon abuse the Intl API?

[slominskir]

The Why does Luxon Exist Readme says the Intl API is horribly abused in order to make the time zone handling work. How exactly? I assume this abuse is how we're able to obtain a timestamp at an arbitrary timezone (potentially different from local time zone and UTC). I'm curious about the cleverness, but also wondering how fragile this is.

[icambron]

It's not fragile at all, but it has a few limitations, such as handling historical zones that have fractional-minute offsets, and likely hypothetical time zones where the offset shifts multiple times in quick succession. It's also unlikely to be a relevant use case for performance optimizations that browsers make to the Intl API. The abuse is that the Intl API will return a structured output (see formatToParts) which can be used to calculate the current offset with a bit of logic. Here is a detailed answer I gave explaining that logic, as part of answer to how someone could, hypothetically, detect ambiguous local times: #1018 (comment).

[slominskir]

Glad to hear it isn't fragile. Looks like wizardry is Intl API provides indirect access to an IANA database, but the logic isn't jumping out. Is the offset guess and check approach used even when just constructing a DateTime at a specific timezone given an ISO string such as:

let dt = luxon.DateTime.fromISO('2023-01-17T02:00:00', {zone: 'America/New_York'});

I see Date.UTC() is used to attempt to avoid the browser local offset, but that doesn't tell you what the offset is at the specified time in the other zone.

[icambron]

luxon/src/zones/IANAZone.js

Line 152 in e781052

const dtf = makeDTF(this.name);

is where that logic lives

[slominskir]

Very clever. Lots of little details like caching DateTimeFormat objects, input validation (NaN), browser quirks (hour 24 instead of 0), feature support (missing formatToParts function), and syntax shortcuts (+d means d.getTime), but the basic idea is:

Given a time zone name and epoch timestamp obtain offset with:

1. Create new Date at given timestamp (browser will adjust to local time)
2. Create a Intl.DateTimeFormat with given time zone name
3. Format to parts (via formatToParts OR if unavailable use hacky string parsing)
4. Create a new Date from the parts, but leverage Date.UTC() to skip the local offset shifting
5. Subtract initial Date from the Date created from parts (by converting each to epoch millis beforehand)

Thanks for the link.