new Date('MMM DD, YYYY HH:MM PM') format is not supported

[Kabeer-Haseja]

Description

In previous versions of React Native, I was able to successfully create a Date object using a string in the following format: "Sep 12, 2024 04:30 PM". For example: new Date('Sep 12, 2024 04:30 PM'); However, in the current version of React Native, this same code now results in an Invalid Date error.

This format worked seamlessly in earlier versions, and it’s a commonly used date string format in many applications. I believe this change may have introduced a regression in how date strings are parsed.

Steps to reproduce

Steps to Reproduce:

1. Run the following code in the latest version of React Native:

const date = new Date('Sep 12, 2024 04:30 PM');
console.log(date);

2. Observe that it outputs Invalid Date.

Expected Behavior:

The Date object should correctly parse the string and create a valid Date instance, as it did in previous versions.

Environment:

React Native Version: 0.75.2

React Native Version

0.75.2

Affected Platforms

Runtime - Android, Runtime - iOS

Output of npx react-native info

System:
  OS: macOS 14.4
  CPU: (12) x64 Apple M3 Pro
  Memory: 19.07 MB / 18.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 14.18.0
    path: ~/.nvm/versions/node/v14.18.0/bin/node
  Yarn:
    version: 3.6.4
    path: /usr/local/bin/yarn
  npm:
    version: 8.19.4
    path: ~/Desktop/EMPG/jarvis-app/node_modules/.bin/npm
  Watchman: Not Found
Managers:
  CocoaPods:
    version: 1.15.2
    path: /Users/kabeerhaseja/.rbenv/shims/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.2
      - iOS 17.2
      - macOS 14.2
      - tvOS 17.2
      - watchOS 10.2
  Android SDK: Not Found
IDEs:
  Android Studio: 2023.3 AI-233.14808.21.2331.11842104
  Xcode:
    version: 15.1/15C65
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.12
    path: /usr/bin/javac
  Ruby:
    version: 3.1.6
    path: /Users/kabeerhaseja/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.3.1
    wanted: 18.3.1
  react-native:
    installed: 0.75.2
    wanted: 0.75.2
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: true
  newArchEnabled: false

Stacktrace or Logs

no crash

Reproducer

not

Screenshots and Videos

No response

[react-native-bot]

:warning:

Newer Version of React Native is Available!

:information_source:

You are on a supported minor version, but it looks like there's a newer patch available - 0.75.3. Please upgrade to the highest patch for your minor or latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If it does not repro, please let us know so we can close out this issue. This helps us ensure we are looking at issues that still exist in the most recent releases.

[react-native-bot]

:warning:	Missing Reproducible Example
:information_source:	We could not detect a reproducible example in your issue report. Please provide either: If your bug is UI related: a Snack If your bug is build/update related: use our Reproducer Template. A reproducer needs to be in a GitHub repository under your username.

[react-native-bot]

:warning:

Newer Version of React Native is Available!

:information_source:

You are on a supported minor version, but it looks like there's a newer patch available - undefined. Please upgrade to the highest patch for your minor or latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If it does not repro, please let us know so we can close out this issue. This helps us ensure we are looking at issues that still exist in the most recent releases.

[react-native-bot]

:warning:	Missing Reproducible Example
:information_source:	We could not detect a reproducible example in your issue report. Please provide either: If your bug is UI related: a Snack If your bug is build/update related: use our Reproducer Template

[cortinico]

2. Observe that it outputs Invalid Date.

What's the exact error you're seeing?

[Kabeer-Haseja]

when i am doing this const date = new Date('Sep 12, 2024 04:30 PM'); console.log(date); iam getting invalid date in console

[cortinico]

Passing over to Hermes. @neildhar is this Intl related?

[avp]

Thanks for the report. This doesn't seem related to Intl given that the only conditionalization in the Date code is in toLocaleString. The code to call the Date parser appears to be called regardless of how Intl is set up, and I don't see any behavior difference on macOS switching Intl on/off.

There's many different kinds of Date string inputs, and which inputs are accepted across which engines can vary significantly, so using the standard-specified input format to Date is the best way to ensure you have consistent behavior.

I can reproduce that new Date('Sep 12, 2024 04:30 PM'); does produce Invalid Date, because we ordinarily parse the weekday ahead of the month and return NaN if one doesn't exist (this input format mostly exists to support round tripping between toString and parse). From looking at our commit history, it's not clear to me that we ever supported this format; I checked out a few older versions of our CLI and it was parsed as Invalid, and it appears to have been this way since it was added in 566725bb766be32e6f5884787b5efab3cce333c2. Do you have a version of Hermes that used to work on so we can verify?

It's likely we could add support for the format that doesn't include the weekday. We will review pull requests to add new Date format support, though if you're going to make particularly large PR to Hermes, please ping us before spending too much time so we can know and help out.

[tmikov]

So, to recap: the spec does not require this format, and Hermes has never supported it. However JSC and v8 engines do support it.

For now we view this as a low priority enhancement and are we unlikely to work on it soon, but we are happy to review PRs adding it.

[Kabeer-Haseja]

@tmikov @cortinico Thank you for the clarification regarding the spec and engine support differences.

While I understand that this format is not explicitly required by the spec, it is still widely used and expected by many developers due to its support in major JavaScript engines like JSC and V8. As a result, many React Native applications that rely on these engines are likely to encounter unexpected behavior when transitioning to Hermes, leading to bugs that are difficult to track down, especially for developers unfamiliar with engine differences.

Given React Native’s push towards Hermes as the default engine, maintaining compatibility with commonly used formats would reduce friction for developers and help smooth the transition. A significant number of apps may already rely on this behavior, and breaking it without a clear alternative creates additional challenges in upgrading and maintaining apps.

I believe ensuring compatibility with formats supported by other major engines should be considered a higher priority, as it affects developer experience, consistency, and ease of migration to Hermes. I would kindly urge the team to reconsider the priority of this issue.