marnusw
`RangeError: Invalid time zone specified:` error caused by usage of `formatInTimeZone` function for some folks
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! 🙇
Still facing the same issue for this Timezone: Asia/Kolkata, Any update or workaround for this?
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 https://github.com/facebook/hermes/issues/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.
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.
Here we are having the same issue with America/Sao_Paulo and America/Cuiaba timezones
