[Im-awesome-Aadi]

Changelog: [Android] [Fixed] Reset Hermes timezone cache on system timezone change
Summary:

When the device timezone changes while the app is running, JavaScript Date still return the local time according to the previous timezone.

This happens because Hermes caches timezone information to improve performance. If the device timezone changes during app runtime, local time calculations continue using the old cached timezone.

Hermes provides a native API, resetTimezoneCache(), to reset this cached information. This PR adds an internal Android module that calls this API whenever the platform detects a timezone change.

Changes:

Kotlin: TimeZoneModule

Listens for Intent.ACTION_TIMEZONE_CHANGED broadcasts

Calls a JNI method to reset Hermes timezone cache

Safely registers/unregisters the receiver during Catalyst lifecycle

Open for unit testing

C++: TimeZoneCache

Provides resetNativeHermesTimeZoneCache() JNI method

Calls hermes::IHermes::resetTimezoneCache()

No-op if runtime pointer is null or runtime is not Hermes

Test Plan:

Java unit tests

Verify broadcast receiver registration/unregistration

Verify native reset hook is invoked on timezone change

[javache]

catalystInstance is a legacy arch concept and javaScriptContextHolder won't work there. Please ensure this works with the new arch.

[Im-awesome-Aadi]

Thanks — that’s a good point. I’ll remove the dependency on CatalystInstance and switch to using RuntimeExecutor so this works correctly in the New Architecture and Bridgeless mode as well. I’ll update the JNI signature to accept a jsi::Runtime& instead of relying on JavaScriptContextHolder.

[troZee]

Hello @javache @Im-awesome-Aadi
I fixed that issue in this library https://github.com/callstack/timezone-hermes-fix

Do you have plans to merge this PR?

[Im-awesome-Aadi]

Hello @javache @Im-awesome-Aadi I fixed that issue in this library https://github.com/callstack/timezone-hermes-fix

Do you have plans to merge this PR?

Hey @troZee , i saw your repo addresses the same issue. I'm trying to fix it in core react-native.
Working on the comment from javache.

[react-native-bot]

This PR is stale because it has been open for 180 days with no activity. It will be closed in 7 days unless you comment on it or remove the "Stale" label.

[react-native-bot]

This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[renelaerke]

Hi @Im-awesome-Aadi, @javache — thanks for working on this; it is a real bug and an easy one to
miss.

We hit it in production (a travel-expense app: entries captured after a flight were dated with the
departure zone's calendar day) and have been running a fix for both platforms since August. I've
written it up with measurements, the real-world cases and a reproducer in #59129.

On the open review point (catalystInstance / javaScriptContextHolder being legacy-arch): on
Android we reach the runtime through ReactContext.getJSCallInvokerHolder() and schedule the
reset on the JS thread with the CallInvoker, then castInterface<IHermes>(runtime) and call
resetTimezoneCache(). That works under the New Architecture and bridgeless mode, and it keeps the
reset on the JS thread by construction. It is triggered from onHostResume and from
Intent.ACTION_TIMEZONE_CHANGED — the broadcast repairs the cache even while the app is
backgrounded.

iOS needs the same treatment (this PR is Android-only): there we observe
UIApplicationDidBecomeActiveNotification and NSSystemTimeZoneDidChangeNotification and run
the reset through the RCTCallInvoker. Measured on an iPhone 17e and a Galaxy S24, same process
across Copenhagen → Sydney: getTimezoneOffset() went 120 → 600 with the reset, and stayed at
120 without it.

Since this PR has been quiet since February, I'm planning to open a PR covering both platforms on
that approach, referencing this one and #59129. If you'd rather carry it forward here, I'm happy
to contribute the iOS half and the New-Arch Android wiring to your branch instead — just say which
you prefer.

[renelaerke]

Small correction: the issue is now #59131 (re-filed through the bug-report form; #59129 is closed as a duplicate).

[troZee]

@renelaerke please use this fix https://github.com/callstack/timezone-hermes-fix