[HOLD for payment 2023-11-13] Android - Bank - After opening calendar for incorporation date day that comes before is selected

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 1.3.95-5 Reproducible in staging?: Y Reproducible in production?: N If this was caught during regression testing, add the test name, ID and link from TestRail: Email or phone of affected tester (no customers): Logs: https://stackoverflow.com/c/expensify/questions/4856 Expensify/Expensify Issue URL: Issue reported by:Applause - Internal Team Slack conversation:

Issue found when executing PR https://github.com/Expensify/App/pull/30845

Action Performed:

1. Open the app
2. Navigate to any Workspace > Bank Account
3. Complete the bank connection flow until step 2 "Incorporation date"
4. Tap "Incorporation date" and select a date, e.g. 01/01/1980
5. Open the calendar again

Expected Result:

The previously chosen date "01/01/1980" is still selected

Actual Result:

The day that comes before is selected (12/31/1979)

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• [x] Android: Native
• [ ] Android: mWeb Chrome
• [ ] iOS: Native
• [ ] iOS: mWeb Safari
• [ ] MacOS: Chrome / Safari
• [ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/e65152bc-d64d-495e-b32b-a2997cda77aa

View all open jobs on GitHub

[melvin-bot[bot]]

Triggered auto assignment to @bfitzexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot[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

[OSBotify]

:wave: Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[melvin-bot[bot]]

Triggered auto assignment to @tgolen (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[tgolen]

@allroundexperts Do you think this has anything to do with some of the changes you've made related to https://github.com/Expensify/App/pull/30845 ?

[erquhart]

@tgolen @allroundexperts new Date() is still in use as an ISO string parser in a few places, Android DatePicker is one of them: https://github.com/Expensify/App/blob/aa30ef2ea44279637eebb2517b4e08ce88f90e7b/src/components/DatePicker/index.android.js#L64

Need to swap that for first one for date-fns parseISO().

This is the same root cause as #30792

[tgolen]

I'm pining @allroundexperts in Slack. If no response, I'll try running git bisect to identify the root cause for sure and either fix it or revert it.

[erquhart]

@tgolen same root cause as #30792 - new Date() parses based on timezone, date-fns parseISO() does not. In #30792 this caused the date to change during entry erratically. In this issue, it causes the calendar component to receive a date that is one day prior to the date value, as the date ISO string is parsed with new Date(). This broke when switching from Moment to date-fns, date parser went from moment() to new Date().

[erquhart]

@allroundexperts opened #30845 to fix #30792.

Here he applied the fix I'm talking about, but it still needs to be applied to line 64, per my comment above, to fix this issue: https://github.com/Expensify/App/pull/30845/files#diff-2a19098ae1f788eb0b65b80d103e4a5d53f159bffdfd1bf8d042de5e83f7e7b9R42

[allroundexperts]

@erquhart I've got it covered. Feel free to review the PR I'm about to create.

[tgolen]

OK, thanks for spelling that out a little more clearly to me. Ah, and here is @allroundexperts now! Thanks for working on this and I'll assign this issue to @allroundexperts.

[allroundexperts]

@erquhart Here's the PR. I think this should be the last instance of Date inside the CalendarPicker. Lemme know if I missed something!

[melvin-bot[bot]]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot[bot]]

The solution for this issue has been :rocket: deployed to production :rocket: in version 1.3.95-9 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:

• https://github.com/Expensify/App/pull/30923

If no regressions arise, payment will be issued on 2023-11-13. :confetti_ball:

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• [ ] External issue reporter
• [ ] Contributor that fixed the issue
• [ ] Contributor+ that helped on the issue and/or PR

For reference, here are some details about the assignees on this issue:

• @allroundexperts does not require payment (Eligible for Manual Requests)

[melvin-bot[bot]]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [ ] [@allroundexperts] The PR that introduced the bug has been identified. Link to the PR:
• [ ] [@allroundexperts] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [ ] [@allroundexperts] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [ ] [@allroundexperts] Determine if we should create a regression test for this bug.
• [ ] [@allroundexperts] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [ ] [@bfitzexpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[bfitzexpensify]

I'd like to clarify the relationship between the solution in this issue and the solution for https://github.com/Expensify/App/issues/30792. It sounds like they had the same root cause, but there are separate PRs to fix the two issues. Are they closely enough aligned to consider them as one solution?

[erquhart]

@bfitzexpensify they are exactly the same issue. new Date() was used instead of parseISO() in a lot of places. #30792 was fixed by updating a few of those instances, this issue was fixed by updating a few more. There are still others.

[tgolen]

@bfitzexpensify I think this is ready to be paid out?

[situchan]

I think I am only the one for payment here. Other contributors' payments are being handled in https://github.com/Expensify/App/issues/30792.

[bfitzexpensify]

Thanks for confirming @erquhart. And yes, the other payments + BZ checklist will happen in https://github.com/Expensify/App/issues/30792, so the only action here is payment for @situchan — the offer has been sent.

[bfitzexpensify]

OK, payment complete, closing this one out.