How to address Date inconsistencies between the Hermes and V8 runtimes in React Native?

Question

I am currently working on a React Native application using the Hermes runtime, and I've encountered some unexpected behaviors related to the Date object when running tests on Node.js with the V8 engine. It seems that there are inconsistencies between the way Hermes and V8 handle dates.

When running tests on Node.js with V8, I noticed that the behavior of the Date object differs from the behavior observed in the Hermes runtime. For example, certain date-related calculations or comparisons that work as expected in Hermes produce unexpected results in the V8 environment.

Here's a simplified example of the code that exhibits the issue:

// V8 Runtime (Chrome)
new Date('2024-03-32') // Invalid Date

// Hermes Runtime (React Native)
new Date('2024-03-32') // 2024-04-01T00:00:00.000Z

• Has anyone else experienced similar issues with date inconsistencies between Hermes and V8 in React Native?

• Are there specific best practices or workarounds for handling date-related operations to ensure consistency across both runtimes?

• Are there known differences in how Hermes and V8 handle the Date object, and if so, what are they?

Answer 1

Consider what MDN has to say:

Non-standard strings can be parsed in any way as desired by the implementation, including the time zone — most implementations use the local time zone by default. Implementations are not required to return invalid date for out-of-bounds date components, although they usually do. A string may have in-bounds date components (with the bounds defined above), but does not represent a date in reality (for example, "February 30"). Implementations behave inconsistently in this case. The Date.parse() page offers more examples about these non-standard cases.
[...]
A library can help if many different formats are to be accommodated.

The spec states:

the value produced by this function is implementation-defined when given any String value that does not conform to the Date Time String Format (21.4.1.32) and that could not be produced in that implementation by the toString or toUTCString method.

So, as long as you ensure that in your production code all dates are valid, it should be fine. If you need to handle invalid dates (such as "March 32rd") consistently, use a library or your own mechanism (which could reject such dates, or handle them however you want).

FWIW, the "Temporal" proposal (if/when it happens) will likely address this pain point (possibly at the cost of having other drawbacks... we will see). If you like its approach to things, you could use one of its polyfills for now. (I'm not recommending that, just pointing out it's an option that exists; it may or may not be a good fit for your needs.)

Filing bugs is probably pointless: implementations probably have strong backwards-compatibility reasons for not changing their behavior (unless they really have to, and when the spec says that the behavior is implementation-defined, they don't have to).