RangeError: Invalid time zone specified: error caused by usage of formatInTimeZone function for some folks

[wordswithchung]

Our DataDog was reporting this error -- RangeError: Invalid time zone specified: -- for about 15 different users internationally. The time zones it would list are definitely not invalid. Some included:

• America/New_York
• Asia/Manila
• Europe/London

The stack trace pointed to getTimeZoneOffSet:

RangeError: Invalid time zone specified: Asia/Manila
  at getTimeZoneOffset 
  at Object.X
  at <anonymous>
  at Array.reduce 
  at format_format
  at formatInTimeZone

It's failing at tzParseTimezone, particularly where it checks isValidTimezoneIANAString(timezoneString). That function relies on the existence of Intl.DateTimeFormat to determine if a time zone is valid or not. Which doesn't work for everyone.

var validIANATimezoneCache = {}
function isValidTimezoneIANAString(timeZoneString) {
  if (validIANATimezoneCache[timeZoneString]) return true
  try {
    new Intl.DateTimeFormat(undefined, { timeZone: timeZoneString })
    validIANATimezoneCache[timeZoneString] = true
    return true
  } catch (error) {
    return false
  }
}

• 96.88% overall https://caniuse.com/?search=datetimeformat
• Reported in Mac Sonoma: https://support.google.com/chrome/thread/231926653?hl=en&msgid=232117132
• Reported in Windows: https://bugs.chromium.org/p/chromium/issues/detail?id=913298

Would it be possible to use a different way to check in isValidTimezoneIANAString? Thank you! 🙇

[sathishdevelops]

Still facing the same issue for this Timezone: Asia/Kolkata, Any update or workaround for this?

[CaptainJeff]

Same issue happening for me in react native

[tao-qian]

We are having the same issue in React Native for Asia/Kolkata

[tao-qian]

After doing some research, my impression is that Intl.DateTimeFormat is system specific, and the Asia/Kolkata issue only happens on iOS (at least based on the errors we have seen in Sentry).

Based on facebook/hermes#1100, we decided to manually map Asia/Kolkata to Asia/Calcutta in our code before passing the timezone to date-fns-tz. And that seemed to have helped.

[toduyemi]

I just had this error thrown. After wrestling with it for hours and tracing the issue to the same line as OC, I realized/found the problem was not with my timezone parameter, but with my date string (the first parameter) which was a string. I don't know why this error was getting thrown in my case, but it was very misleading for the error to flag where it did with the message it did. After changing to a UTC epoch timestamp (number), I haave has zero problems, including the timezones all of the above commenters have listed.