Proposal: parseISO from date-fns is pretty slow, we can replace parseISO from date-fns with Date()

[mountiny]

Coming from here

### Problem

date-fns is a great library but it’s underperforming in some scenarios For example, using parseISO function takes around 112 ms and it’s a lot of time for a utility function. The main problem we have at our hands is most of the work is already been done in moving from moment to date-fns . While date-fns is a good library and works well in other scenarios, which otherwise haven’t been reported by profiler but parseISO is such a utility function which is consuming noticeable milliseconds and reported by profiler.

Solution:

We have two solutions here:

1. Given our efforts in migrating from moment to date-fns , we can use stock new Date(dateToParse) in place of parseISO and it works really well. Looking at the benchmarks, parseISO can perform around 69-71k operations per second, whereas new Date can perform around 379k operations per second.
2. We can introduce dayjs which we can use in place of parseISO and in rest of the places we can still use date-fns unless in future if Profiler states to us that this certain function is slow, so we can gradually replace date-fns from the codebase. In our codebase, we are using this parseISO function in only a couple of places and we can easily refactor the codebase. A good alternative to date-fns is dayjs and it’s also a lighter one, only 2KB in size. Using dayjs in place of parseISO function, we see that it takes around 23 ms in Profiler. Also, if we take a closer look at the comparisons benchmarks, parseISO can perform around 69-71k operations per second, whereas dayjs can perform around 167k operations per second, which is a lot of difference.

Since we have spent a lot of efforts in migrating from moment to date-fns and certainly it’s better than moment but in some scenarios, some utility functions of date-fns are underperforming. Ideally, we can replace those underperforming parts with new Date and in future, if there are any other underperforming utility functions reported by Profiler, we can decide whether it’s fixable by using stock Date or now it is time to gradually adopt dayjs or any other efficient date library.

Conclusion

Lets use the Date() construct for now, we dont really have a clear problem which would be solved by introducing the dayjs right now

[melvin-bot]

Current assignee @muttmuure is eligible for the Bug assigner, not assigning anyone new.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[mountiny]

@waterim did you get to this by any chance?

[waterim]

@mountiny Here is a PR

[mountiny]

We got two issues for this 😂 closing in favour of #29271