App: [HOLD for payment 2023-09-29] [$2000] Web - user not able to save last enable date of birth

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


Action Performed:

  1. Set the Date & Time on your Mac to India Standard Time a. On Mac > System Settings > General > Date & Time b. Enable “set time and date automatically” & Disable “Set time zone automatically using your current location” c. Choose New Delhi - India as your “Closest City” d. Disable “set time and date automatically”

  2. Sign into https://staging.new.expensify.com/settings on the Chrome browser

  3. Click the Profile icon (settings) > Profile > Personal details > Date of birth

  4. Select the most recent available date

  5. Notice date error

Expected Result:

user should able to save enable date

Actual Result:

error appears on select latest enable date

Workaround:

unknown

Platforms:

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

  • Android / native
  • Android / Chrome
  • iOS / native
  • iOS / Safari
  • MacOS / Chrome / Safari
  • MacOS / Desktop

Version Number: v1.3.53-1 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 Notes/Photos/Videos: Any additional supporting documentation

https://github.com/Expensify/App/assets/43995119/62597452-cca4-42c9-9a41-6b49594a38bd

Expensify/Expensify Issue URL: Issue reported by: @gadhiyamanan & @Pujan92 Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1691498421013379

View all open jobs on GitHub

Upwork Automation - Do Not Edit
  • Upwork Job URL: https://www.upwork.com/jobs/~011fd6c960bd909251
  • Upwork Job ID: 1689782476244590592
  • Last Price Increase: 2023-08-24
  • Automatic offers:
    • 0xmiroslav | Reviewer | 26685187
    • gadhiyamanan | Reporter | 26685188

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 72 (49 by maintainers)

Most upvoted comments

@blazejkustra’s proposal looks good to me. 🎀 👀 🎀 C+ reviewed

@Christinadobrzyn please hold my payment yet and just close the issue. I am tracking myself and will ping here once ready.

No need regression test. This is super edge case. No one will likely to select their age as 5 (min) or 150 (max).

Contributor was assigned on Sep 14 C+ approved on Sep 16 PR merged on Sep 18 without changes requested Sep 16, 17 was weekend

So I’d say actual timeline is within 2 days

@Gonals is not on parental leave 😄

I think @Gonals is on parental leave. If so, should we reassign engineer? cc: @Christinadobrzyn

I believe @Pujan92 proposal partially doesn’t work, I tested it on Honolulu timezone (it was 3:41AM 21-08-2023). Basically it doesn’t work the other way around (it allows 2018-08-22 while it should be forbidden).

Agree @blazejkustra , for GMT- timezones my solution seems to create a problem and allows the next date which shouldn’t be allowed. Whereas parse will directly set the timezone with the start time which is given as a reference date timezone in the last param.

Still waiting on proposals

@Christinadobrzyn proposals are available, seems review is pending…

Thanks @Pujan92! I can reproduce this with those additional steps. Updated the steps in the OP and added an External label

For Mac these are the steps to update timezone and set any GMT+ city.

  1. Select “System Preferences” from the Apple menu.
  2. Under the “Date and Time” option, click on “Time Zone.”
  3. Deselect the “Set Time Zone Automatically Using Current Location” and update the city manually.

https://github.com/Expensify/App/assets/14358475/ddef3739-3fe6-4b50-87bb-442d320fa2c2

I can’t reproduce either - asking for more guidance in the Slack thread -

@Christinadobrzyn It can be reproducible for the GMT+ timezones. for GMT- it won’t be reproducible as it(current code) considers previous day for the error condition.

I don’t think this needs to be a deploy blocker as it only affects users who are exactly 5 years old. Removing the label.