RangeError: Invalid time value, on RN Android

[cyanzule]

Hi! 👋

Firstly, thanks for your work on this project! 🙂

Today I used patch-package to patch @date-fns/[email protected] for the project I'm working on.

Environment

Base React Native project, as in, without Expo CLI, Android builds (compile SDK 34, tested on Android 14, both emulator and physical device), with dependencies:

    "@date-fns/tz": "^1.1.2",
    "date-fns": "^4.1.0",
    "intl-pluralrules": "^2.0.1",
    "react-native": "0.74.5",

Not sure on the impact of that polyfill, but adding it for reference and how a polyfill might be needed to begin with. Timezone doesn't seem to matter, but I've added mine in Replication.

Replication

All dates parsed with a time zone print Date { NaN } when logged, with the following code snippet being enough for a thrown exception:

new TZDateMini(new Date(), 'Atlantic/Madeira')

Further Investigation

So it seems this is the thereabout same issue as in #8, only the issue only focused on iOS builds. When running the suggested troubleshooting code there, it outputs the following:

new Intl.DateTimeFormat("en-GB", { timeZone: "Asia/Singapore", hour: "numeric", timeZoneName: "longOffset" }).format(new Date())

// GMT+08:00 (hour: 17)

which seems to break calcOffset, returning NaN. You can further verify this textual discrepancy in the Expo demo supplied on the original issue referenced above, when swapping to the Android build.

Further investigation lead to me finding out that, by default, Android only correctly formats dates for the en-US locale, unless you modify its compiling parameters, adding 6MB for the trouble. Hermes, the JS engine React Native runs on, simply outputs whatever the underlying operating system returns for Intlcalls, I think, but I haven't personally tested if using org.webkit:android-jsc-intl:+ does resolve the issue.

I don't think this patch below is the solution we should publish, changing the default locale and all, but it works as intended and doesn't break iOS builds.

Package patch

Here is the diff that solved my problem:

diff --git a/node_modules/@date-fns/tz/tzOffset/index.cjs b/node_modules/@date-fns/tz/tzOffset/index.cjs
index c6dae93..d78129d 100644
--- a/node_modules/@date-fns/tz/tzOffset/index.cjs
+++ b/node_modules/@date-fns/tz/tzOffset/index.cjs
@@ -19,7 +19,7 @@ const offsetCache = {};
  */
 function tzOffset(timeZone, date) {
   try {
-    const format = offsetFormatCache[timeZone] ||= new Intl.DateTimeFormat("en-GB", {
+    const format = offsetFormatCache[timeZone] ||= new Intl.DateTimeFormat("en-US", {
       timeZone,
       hour: "numeric",
       timeZoneName: "longOffset"
diff --git a/node_modules/@date-fns/tz/tzOffset/index.js b/node_modules/@date-fns/tz/tzOffset/index.js
index ee975c9..6bf9624 100644
--- a/node_modules/@date-fns/tz/tzOffset/index.js
+++ b/node_modules/@date-fns/tz/tzOffset/index.js
@@ -16,7 +16,7 @@ const offsetCache = {};
  */
 export function tzOffset(timeZone, date) {
   try {
-    const format = offsetFormatCache[timeZone] ||= new Intl.DateTimeFormat("en-GB", {
+    const format = offsetFormatCache[timeZone] ||= new Intl.DateTimeFormat("en-US", {
       timeZone,
       hour: "numeric",
       timeZoneName: "longOffset"

This issue body was partially generated by patch-package.

[hc-12]

I also face the same issue in RN, where Android would crash but not iOS.

The patch has been tested and proven to work