Luxon: Is there an equivalent to moment.parseZone?

[ericmorand]

Hi,

In Twing, I'm currently using Luxon for everything date-related but I unfortunately have to use moment for just one case:

            parsedUtcOffset = moment.parseZone(date as string).utcOffset();

Users can call one of Twing date filter with a string representing the date, including the timezone. In this case, the timezone set by the user has to be respected and thus I have to be able to parse it from the string passed as parameter.

I couldn't find a way to do that with Luxon and I'd like to be able to get rid of moment entirely. Is there an equivalent that I missed?

[icambron]

Yup, use the setZone option in fromFormat. There's some documentation here

[ericmorand]

I just had the chance to test your solution today and it works perfectly. The last piece of code depending on moment is now gone. Many thanks.

[joetidee]

Is there a way to set the zone using the offset data from the ISO 8601 string? My guess is that timezone and offset are different things and are not interchangeable (?)

[GillesDebunne]

You are right.
A given time zone may have different offsets (for instance because of daylight saving time), and a given offset is usually shared by several time zones, all roughly located on the same longitude.

[joetidee]

Do you know if there is any intention to add a parseZone equivalent to luxon? Or, is it not correct to simply work with a date that has the offset, because without the zone it doesn't know when to apply DST?

[GillesDebunne]

As @icambron said, use the setZone option in fromFormat or fromISO. This will set your DateTime to a fixed offset time zone, as defined in your string, like parseZone does.

let dt = DateTime.fromISO("2016-05-25T09:08:34.123+06:00", { setZone: true });
expect(dt.zone.name).toBe("UTC+6");

However, as you said, DST will not be applied in calculations. There is no way to fix this, since the offset information may correspond to different time zones, which may have different DST rules.

[icambron]

If you parse a string that contains an IANA zone like "America/New_York" (and the corresponding parsing token), and use setZone, Luxon will respect the DST. But like Giles said, Luxon has no way to know what the DST rules are given just an offset.