The timezone plugin is not compatible with React Native Hermes engine

[dortamiguel]

The timezone plugin throws a timezone RangeError error when calling .tz because React Native Hermes engine doesn't has support for Intl timezones and toLocaleString

This two lines are the ones that are throwing the error

https://github.com/iamkun/dayjs/blob/dev/src/plugin/timezone/index.js#L20

https://github.com/iamkun/dayjs/blob/dev/src/plugin/timezone/index.js#L98

Could be posible to update the plugin to not depend on Intl and toLocaleString('en-US', { timeZone: timezone }) ?

[sohcah]

I've been facing the same issue today.

With the formatjs polyfill that's recommended, I've got it partially working:
dayjs.tz("2013-11-18 11:55", "America/Toronto") returns correctly with "2013-11-18T16:55:00.000Z"

However, it's not fully working:
dayjs("2013-11-18 11:55").tz("America/Toronto") returns null

So, with a polyfill I'm able to get Parsing in Zone to work, but not Converting to Zone.

[dortamiguel]

@sohcah what polyfill setup are you using? I tried to use formatjs but I didn't managed to make it work

[sohcah]

@ellipticaldoor
I created an empty polyfill.ts file, as the polyfill isn't required on iOS or Web, and created a polyfill.android.ts file which contains the following: https://gist.github.com/sohcah/c223886c3e40a7b9c0283cd0213e2a54
I've got a few console logs in there to test Converting and Parsing, giving me this output:

Then I'm just putting import './polyfill.ts'; in my App.tsx file.

[sohcah]

My converting issue seems similar to #1356... so possibly related?

[sohcah]

Looks like Date.toLocaleString() works differently with the Polyfill.
Running new Date().toLocaleString("en-US", { timeZone: "America/Toronto" }) in a browser returns "2/9/2021, 9:03:52 AM", whilst with the polyfill it returns 2/9/2021.

[sohcah]

// @ts-ignore
Date.prototype._toLocaleString = Date.prototype.toLocaleString;
// @ts-ignore
Date.prototype.toLocaleString = function (a, b) {
  if (b && Object.keys(b).length === 1 && "timeZone" in b && a === "en-US") {
    return Intl.DateTimeFormat("en-us", {
      year: "numeric",
      month: "2-digit",
      day: "2-digit",
      hour: "2-digit",
      minute: "2-digit",
      second: "2-digit",
      hour12: false,
      timeZone: b.timeZone,
    })
      .format(this)
      .replace(/(\d{2})\/(\d{2})\/(\d{4}),/g, "$3-$1-$2");
  }
  // @ts-ignore
  return this._toLocaleString(a, b);
};

I've ended up, at least temporarily, using this patch in my polyfill.android.ts (plus all the formatjs stuff from before). It's absolutely not perfect... and really not a great solution, but seems to sort the issue for me.

[dlebedynskyi]

Had run into same issue as @sohcah. Any update as official fix would be appreciated. Polyfills claim spec compliance
https://formatjs.io/docs/polyfills/intl-datetimeformat/#default-timezone

I had to patch dayjs to isolate one call with ^^ workaround

[troZee]

Had run into same issue as @sohcah. Any update as official fix would be appreciated. Polyfills claim spec compliance
https://formatjs.io/docs/polyfills/intl-datetimeformat/#default-timezone

I had to patch dayjs to isolate one call with ^^ workaround

Could you provide a code snippet ?

[devinjameson]

It's possible this might solve the problem on Android. In app build.gradle:

/**
 * The preferred build flavor of JavaScriptCore.
 *
 * For example, to use the international variant, you can use:
 * `def jscFlavor = 'org.webkit:android-jsc-intl:+'`
 *
 * The international variant includes ICU i18n library and necessary data
 * allowing to use e.g. `Date.toLocaleString` and `String.localeCompare` that
 * give correct results when using with locales other than en-US.  Note that
 * this variant is about 6MiB larger per architecture than default.
 */
def jscFlavor = 'org.webkit:android-jsc-intl:+'

[dlebedynskyi]

@troZee

create gist with patch we are using now
https://gist.github.com/dlebedynskyi/81ff281b0db6aa69cdb360a1b609fb8a

this is essentially your suggested change, but as patch

+                // HACK https://github.com/iamkun/dayjs/issues/1377
+                i = Intl.DateTimeFormat('en-us', {
+                    year: 'numeric',
+                    month: '2-digit',
+                    day: '2-digit',
+                    hour: '2-digit',
+                    minute: '2-digit',
+                    second: '2-digit',
+                    hour12: false,
+                    timeZone: t,
+                })

@devinjameson

It's possible this might solve the problem on Android. In app build.gradle:

We are trying to avoid this exactly. There are bugs in current JSC used in RN related to DST (in Brazil for example).
You also need to use https://formatjs.io/docs/polyfills for Hermes (RN 0.64)
Last adding JSC increases your apk size by >3mb

[Rc85]

@troZee

create gist with patch we are using now
https://gist.github.com/dlebedynskyi/81ff281b0db6aa69cdb360a1b609fb8a

this is essentially your suggested change, but as patch

+                // HACK https://github.com/iamkun/dayjs/issues/1377
+                i = Intl.DateTimeFormat('en-us', {
+                    year: 'numeric',
+                    month: '2-digit',
+                    day: '2-digit',
+                    hour: '2-digit',
+                    minute: '2-digit',
+                    second: '2-digit',
+                    hour12: false,
+                    timeZone: t,
+                })

@devinjameson

It's possible this might solve the problem on Android. In app build.gradle:

We are trying to avoid this exactly. There are bugs in current JSC used in RN related to DST (in Brazil for example).
You also need to use https://formatjs.io/docs/polyfills for Hermes (RN 0.64)
Last adding JSC increases your apk size by >3mb

Patched it and now I'm getting this error.

ReferenceError: Property 'Intl' doesn't exist

[dlebedynskyi]

Patched it and now I'm getting this error.

you are missing Intl library, probably on React Native Android - make sure you have JSC with Intl flavor, or latest Hermes with Intl, or add polyfill.

[HenriqueeLoopes]

@dlebedynskyi Intl has been added in the latest version(0.8.1) of Hermes.

[DeveloperTheExplorer]

It's possible this might solve the problem on Android. In app build.gradle:

/**
 * The preferred build flavor of JavaScriptCore.
 *
 * For example, to use the international variant, you can use:
 * `def jscFlavor = 'org.webkit:android-jsc-intl:+'`
 *
 * The international variant includes ICU i18n library and necessary data
 * allowing to use e.g. `Date.toLocaleString` and `String.localeCompare` that
 * give correct results when using with locales other than en-US.  Note that
 * this variant is about 6MiB larger per architecture than default.
 */
def jscFlavor = 'org.webkit:android-jsc-intl:+'

You are a life saver <3

[mattijsf]

@dlebedynskyi Intl has been added in the latest version(0.8.1) of Hermes.

But it doesn't come with timezone conversion support. When using Hermes on iOS, Intl is not available entirely.