Is there a reason for showing GMT+1 and not BST?

[johnend]

As in the title.

We recently implement Luxon on a work project and when showing local times to UK folks the times either come out as GMT or GMT+1. In the US times are shown as either EST or EDT. So I'm just curious why Luxon uses a numbered offset for British Summer time and not just the BST abbreviation?

[icambron]

Luxon uses the built-into-the-runtime Intl API to get those strings. And annoyingly, the way the data backing that API works, it knows the offset abbreviations for the US if the locale is en-US and the offset abbreviations for the UK if the locale is en-GB:

new Intl.DateTimeFormat("en-US", { timeZoneName: "short", timeZone: "America/New_York"}).format() //=> '10/1/2021, EDT'
new Intl.DateTimeFormat("en-UK", { timeZoneName: "short", timeZone: "America/New_York"}).format() //=> '01/10/2021, GMT-4'
new Intl.DateTimeFormat("en-US", { timeZoneName: "short", timeZone: "Europe/London"}).format() //=> '10/1/2021, GMT+1'
new Intl.DateTimeFormat("en-UK", { timeZoneName: "short", timeZone: "Europe/London"}).format() //=> '01/10/2021, BST'

So how does Luxon choose what locale to use? Depends on the use case:

1. For most methods in Luxon, it uses the browser's locale. So for example, if your computer is set to use en-GB, you'll get this behavior:

// you probably don't need the setZone(), but I do
DateTime.now().setZone("Europe/London").offsetNameShort //=> BST

If your computer was set to some other locale, like mine, you could do:

DateTime.now().setZone("Europe/London").setLocale("en-GB").offsetNameShort //=> BST

You can also set the locale globally through the Settings class in Luxon.

The same logic applies to toLocaleString(), etc.

2. Specifically for the toFormat() method, we use en-US by default, regardless of the locale of the environment. See offsetNameShort and 'ZZZZ' do not match and output changes depending on timezone #1019 for a full explanation of this, and also more context on the issue you encountered generally. I'll also add that if you're using toFormat for user-visible strings, you should reconsider.

What's dumb here, of course, is that Intl doesn't have both sets of strings for both locales. But Luxon doesn't control that.

[johnend]

That's interesting and thanks for the answer, unfortunately we need to use toFormat() due to restrictions from the design system for how we present dates and times to our users. It's also interesting that BST is GMT+1 in en-US locale when the US offsets are EST, EDT etc.