Incorrect timeZone information provided for Intl.DateTimeFormat for Asia/Kolkata timezone on iOS

[BurgerZ]

Bug Description

I use luxon library for DateTime related operations in my React Native projects. And I accidentally noticed that when using the Asia/Kolkata timezone I get a null DateTime, for other timezones I get the actual DateTime object without any issues.

Luxon code to reproduce this:

const date = DateTime.now().setZone("Asia/Kolkata"));
console.log("date:", date);

The console log shows date: null.

But if using other timezones, for example Europe/Madrid, I get the right DateTime response:

const date = DateTime.now().setZone("Europe/Madrid"));
console.log("date:", date);

The console log shows date: 2023-08-17T18:09:09.866+02:00.

I created the issue at the Luxon repository, and got response that this could be the Hermes issue, because DateTime.now() uses Intl.DateTimeFormat under the hood.

Results with Intl are the same: for web and Android the date in Asia/Kolkata is being created without issues, but not for iOS, where I get Incorrect timeZone information provided error.

Steps To Reproduce

Code called for Intl implementation:

const date = new Intl.DateTimeFormat('en', { timeZone: "Asia/Kolkata"}).format(new Date());
console.log("date:", date);

Gives an error above on iOS.

const date = new Intl.DateTimeFormat('en', { timeZone: "Europe/Madrid"}).format(new Date());
console.log("date:", date);

Works as expected.

I've created the Expo snack with both luxon and Intl approaches - Luxon DateTime issue

The Expected Behavior

Return correct DateTime for give timezone.

---

Hermes version:
React Native version (if any): latest
OS version (if any):
Platform (most likely one of arm64-v8a, armeabi-v7a, x86, x86_64):

[tmikov]

Hermes does not provide its own timezone data, it uses what is available from the underlying OS. Apparently MacOS and iOS support Asia/Calcutta, so in my tests this works:

   new Intl.DateTimeFormat('en', { timeZone: "Asia/Calcutta"}).format(new Date());

[BurgerZ]

Thanks!
It seems that I need to add some workaround to fix this issue, because timezone is being determined automatically, than it is used to build the DatTime object, which is null in case of iOS and Kolkata (I've found out that macOS and iOS uses deprecated Calcutta timezone).