MM/DD/YYYY format leads to invalid date

[crutchcorn]

Bug Description

When using dates like 12/12/2022 or 11/30/2000 00:00:00, I get Date invalid.

While I know that this is a non-standard date format, both JSC and V8 support these date formats.

I'm also happy to submit a PR to fix this, so long as the team is okay with it.

This ticket is a duplicate of #647, which seems to have been closed errantly.

• [x] I have run gradle clean and confirmed this bug does not occur with JSC

Hermes version: 0.11.0 React Native version (if any): 0.71.0 OS version (if any): Platform (most likely one of arm64-v8a, armeabi-v7a, x86, x86_64):

Steps To Reproduce

1. new Date("12/12/2022")
2. See Invalid Date when logging to console.log

code example:

The Expected Behavior

It should parse as December 12th, 2022.

[tmikov]

Reclassifying as an enhancement, since it is not a bug to omit a non-standard format.

[tmikov]

We always gladly welcome PRs, although of course there are no guarantees that any specific PR will be accepted. If it turns into a lot of code or significant changes, please ping us before doing too much work.

[fbmal7]

Here is a recent change to our date parsing that may help you find some relevant locations in the codebase.

[fbmal7]

I would urge you to think through all of the edge cases when it comes to this kind of format as well. And then put them into tests once you finish. For example, are you allowed to mix and match? Can you do new Date("12/12 2022")? Or new Date("12-12/2022")? As this is nonstandard, the best way to guide your implementation is to just explore what V8 and JSC do when you throw these inputs at them, and then make your implementation consistent with that. The code pointers in the commit I linked are very relevant as that was modifying the separators we allow between the D/M/Y numerical values, which is what you are seeking to do. However, your change would be more complicated as we currently don't allow only numerical values for DD/MM/YYYY at all.

[joe-sam]

I feel really bad about saying this but as a rule you should probably just stick to the standard or revise the standard.

There will always be some edge case applying to some International time zone/user-input/server-timezone that will slip through and the divergence between V8 / JSC and Hermes could probably cause immense chaos when porting that will only show up at some random date and time.

It might be better to just mask the user input and output in and out of the desired format and forward the parsing to the well tested standard functions.

You and other contributors to this might also probably have a major implementation conflict every time for the parsing of the edge case, the pros/cons between selection of the V8 versus JSC parsing implementation and here is where an definite standard would be really useful.

[adilsaeed31]

Hi All, I tried to get the difference in React Native with Hermes, but it was not working for me, I tried lots of options but finally, I came up with the below solution.

moment().diff( moment(parseDate, 'DD/MM/YYYY hh:mm:ss a'), 'years' )

Always provide the time format of the date that you are trying to convert so it will not parse it properly and it will work fine.

Thanks

[ngregory-rbi]

Everyone is mentioned standard, but no one mentioned what standard specifically, so I thought I'd link it.

EcmaScript 6 (ES6), which Hermes is planning to target, requires ONLY date parsing of the format: YYYY-MM-DDTHH:mm:ss.sssZ.

According to the section on the Date constructor that takes in a single value, EcmaScript requires it to parse a string "in exactly the same manner as for the parse method" (see Step 3.b.ii). In the section on that parse method, EcmaScript notes (emphasis mine):

The function first attempts to parse the format of the String according to the rules (including extended years) called out in Date Time String Format (20.3.1.16). If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats.

The specific use of "may" here indicates anything other than the above format is optional to provide parsing for.

[joe-sam]

The problems with date manipulation are really extensive and can cause numerous headaches. But to summarize the root crux of the problem is often that there is no clear audit trail in the native javascript date manipulation primarily because javascript dates are not immutable. Many longstanding date engines like JSC are extremely outdated in their thinking paradigm. This is a fundamental flaw which cannot be resolved easily. One should reach for a modernized date engine library such as Luxon is an evolution of the great Moment.js library, rather than reinventing this wheel. Luxon is based on various fundamental postulates of which immutability is a chief proponent. This allows a clear and easy to follow audit trail should you ever need to track down a buggy date across server/sites/timezones stack traces and data storage systems.

[ayelenguini]

Hi! Any updates on this? I have an app that consumes a service with that type of date and after upgrading the RN from 69.2 to 72.2 it's broken and shows Invalid Date. I'm using MM/DD/YYYY format date. Any workarounds that could be done from the frontend side are also welcome.

[adilsaeed31]

@ayelenguini you need parse your date if the date format is NON-RFC/ISO8601. configure your moment as below mentioned moment(date, 'MM/DD/YYYY').format('MM/DD/YYYY') as you see I've given the 2nd argument in the moment method this is required if your date format does not fall under RFC/ISO8601.

[diamont1001]

Any solution? Why it's different from V8/JSC?

[vksgautam1986]

any work around ?

[adilsaeed31]

@vksgautam1986 @diamont1001 i'm using momentjs, and momentjs by default consider the given date as ISO8601 if your date format is not like that then you have to provide the date format moment(date, 'MM/DD/YYYY') like this then it will work properly without any issues.

[vksgautam1986]

@adilsaeed31 not working properly , giving crashes in the build

[adilsaeed31]

@vksgautam1986 Could you please show me how you are doing in code, and what the date format is coming, in the above comments I've given you the example only.

also, follow the below link doc of Momentjs https://momentjs.com/docs/#/parsing/string-format/

[tmikov]

Is this a duplicate of https://github.com/facebook/hermes/issues/647?

[KingAmo]

any update on this?

[tmikov]

There is no update. This is still in our TODO list, but we consider this fairly low priority, since we haven't received a specification or an explanation of the desired behavior. I am sorry.

[ravindraguptacapgemini]

@crutchcorn Do we have a workaround for this issue?

[fabiendem]

Created a Snack to demonstrate the issue: https://snack.expo.dev/@fabien_hinge/hermes-and-date-format To test it:

• launch the snack on the Web, timestamp is displayed ✅
• Run it on Android, timestamp shows as NaN 💔

So, the behaviour will be inconsistent between the Web target and an Android/iOS (Hermes) one.

A related issue is that our devs will write their Jest tests (running in Node) on the date parsing and get a false positive in the tests. But once we run the code on a device (Hermes), the feature will be broken.