"Missing internal slot calendar-id" error on iOS in React Native

[AlteredConstants]

When calling toLocaleString on any of the date-time classes in a React Native app on an iOS device, I receive the error "Missing internal slot calendar-id".

I believe the problem is that Intl.DateTimeFormat().resolvedOptions().calendar is undefined on that platform currently (a recent change from Apple, I believe) and it's not clear to me from the description in MDN whether this is valid per the spec or not.

I suspect this is likely an issue with React Native, not specifically this library, so I've reported it there also, but I figured I'd open a report here as well in the hopes that it's possible to handle this scenario more gracefully.

Reproduction

You can see the issue with this Expo Snack by clicking the "Launch Snack" button (with iOS selected) here:
https://snack.expo.dev/@miramar-zeff/temporal-ios-tolocalestring-bug?platform=ios

The essential part is this call to toLocaleString:

Temporal.Now.plainDateISO().toLocaleString()

Workaround

Interestingly, using Intl.DateTimeFormat directly instead does work (though obviously much more awkward, verbose, and potentially limiting):

Intl.DateTimeFormat().format(
  new Date(
    Temporal.Now.plainDateISO().toZonedDateTime(
      Temporal.Now.timeZoneId()
    ).epochMilliseconds
  )
)

https://snack.expo.dev/@miramar-zeff/temporal-ios-tolocalestring-workaround?platform=ios

I'm not sure if this is because the implementation of Intl.DateTimeFormat on React Native is handling this missing calendar value more appropriately, using some other value on iOS for this information, or just not using it at all.

Edit: It also looks like the fullcalendar polyfill doesn't have this issue. Not sure if they're just not doing a check that should be happening or if they're handling this case correctly.

[ptomato]

Thanks for the bug report. It's hard to tell whether undefined is legal there per the ECMA-402 spec, because of ResolveLocale not exactly being clear on the format of the internal locale data. But I suspect it may be disallowed, from reading Properties of Intl.DateTimeFormat Instances where it says that legal values for the [[Calendar]] slot are strings, not undefined.

This could probably be worked around with a 1-line change:

SetSlot(dtf, CAL_ID, ro.calendar ?? 'iso8601');

(in line 147 of intl.ts.)
But I guess before confirming that iso8601 is the right default value to put there, we'd have to know how the Intl.DateTimeFormat on iOS actually behaves when calendar is undefined!

[AlteredConstants]

@ptomato Cool, yeah, that's kind of what I figured as well. I attempted to test out a similar charge (using gregory instead of iso8601 since that seemed to be what the other platforms were returning for that value) but couldn't get it to work properly. That said, I was trying to patch the minimized code so I might have messed something up there.

(Side node: it might be nice to include unminimized but JS-compiled code in the package for patching like this. A lot of other libraries seem to do so for module/CommonJS importing and only minimize for UMD, but I don't know the current best practice with this for libraries, to be honest.)

Is there anything you'd like me to help test in terms of the Intl.DateTimeFormat implementation? My guess was that because it's using Date, it doesn't really use calendar at all since my understanding is that Date only supports one calendar, but I don't know. If there's some particular example that would help elucidate what's happening there, let me know and I can test it out.

[ptomato]

@AlteredConstants I'd be curious to know the full contents of the object returned from new Intl.DateTimeFormat().resolvedOptions()...

[AlteredConstants]

@ptomato I don't currently have access to a real device to test on, but using the Expo Snack (which seems to match the real-device behavior—I assume it's using an iOS simulator—at least in terms of the calendar value), I get this:

{
  day: "numeric",
  year: "numeric",
  timeZone: "America/Phoenix",
  month: "numeric",
  locale: "en-US",
}

[ptomato]

Looking at facebook/hermes#1716 it looks like they've acknowledged this is a bug in Hermes on macOS. So probably the focus here should be to work around that bug.

Probably the undefined calendar is supposed to be the default calendar guessed from the locale. I'm not sure how we can realistically guess it if the engine doesn't provide it, so maybe having ?? 'iso8601' is sufficient.