8

I am trying the ECMA-402 International API to get the timezone abbreviation in a timezone that is not the local timezone (server timezone is UTC). I know other ways to get this. I am trying to understand the limitations of and make best use of the International API. I can get the full timezone name and map it myself, but as the abbreviations are in the IANA tz database and the International API is supposed to be based on this, it seems it should be able to produce them, which makes me think I am doing something wrong.

I have the following code:

    const fmt = new Intl.DateTimeFormat('en', {
        year: 'numeric',
        month: '2-digit',
        day: '2-digit',
        hour: '2-digit',
        minute: '2-digit',
        second: 'numeric',
        fractionalSecondDigits: 3,
        hour12: false,
        weekday: 'short',
        timeZoneName: 'short',
        timeZone: 'Pacific/Auckland' 
    });

    const now = new Date();
    console.log(fmt.format(now));

    const fmt2 = new Intl.DateTimeFormat('en', {
        year: 'numeric',
        month: '2-digit',
        day: '2-digit',
        hour: '2-digit',
        minute: '2-digit',
        second: 'numeric',
        fractionalSecondDigits: 3,
        hour12: false,
        weekday: 'short',
        timeZoneName: 'short',
        timeZone: 'America/Los_Angeles' 
    });

    console.log(fmt2.format(now));

In both node 12.16.1 and Firefox 73.0.1 this produces output like the following:

Wed, 04/08/2020, 18:14:50 GMT+12
Tue, 04/07/2020, 23:14:50 PDT

The America/Los_Angeles timezone gets the timezone abbreviation as expected but the Pacific/Auckland timezone does not. The IANA tz database has the abbreviations for Pacific/Auckland and the operating system (Debian Linux) produces them.

Is there anything I can do differently to get the abbreviations from the International API? Or is this simply the state of the art?

I note that both luxon and date-fns-tz depend on the International API and they also fail to produce the abbreviations for Pacific/Auckland.

Ian
  • 2,078
  • 2
  • 19
  • 19

1 Answers1

8

Most implementations of the ECMAScript Internationalization API derive time zone abbreviation strings from Unicode CLDR, not from IANA. Abbreviations in IANA are English-only, and many have been removed in recent years, where it was found they had been invented.

Unfortunately, there are very few time zone abbreviations actually included in the CLDR data set.

In general, time zone abbreviations are difficult to get agreement on. In several cases, more than one abbreviation is used for the same time zone. Some cultures switch to English abbreviations, while others have their own in their own languages, and many cultures simply don't use them at all.

Given all this, I'd say you should still use the output given by the Intl API. Where abbreviations are available you'll have them, and where they aren't you'll have a numeric offset. Yes - that's the current state of the art.

Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
  • Thank you for the reference to the Unicode CLDR. I wasn't aware of it. And I misinterpreted section 6.4 of ECMA-402 to mean the IANA database was to be used, rather than, as it says, that the zone and link names in it are to be used. This is a very helpful correction of my understanding. – Ian Apr 08 '20 at 20:55
  • 1
    Yeah, CLDR also uses IANA zone/link names as a normative reference. In general, IANA is the source for the offsets/transitions, while CLDR is the source for localizations. Abbreviations are in the weird gray area, and handled poorly in both. Neither will own up to being "the standard" although they are the closest thing we have to one. – Matt Johnson-Pint Apr 09 '20 at 02:13