fix: date picker off by one day

[mjmasn]

Summary

The Material DatePicker returns a midnight UTC timestamp when picking a date, so when the timezone was behind UTC (e.g. PST), the final date would be set to the previous day to the one picked.

Test Plan

Tested in Android Emulator set to PST timezone

What's required for testing (prerequisites)?

What are the steps to reproduce (after prerequisites)?

Compatibility

OS	Implemented
iOS	n/a
Android	✅

Checklist

• I have tested this on a device and a simulator
• I added the documentation in README.md
• I updated the typed files (TS and Flow)
• I added a sample use of the API in the example project (example/App.js)
• I have added automated tests, either in JS or e2e tests, as applicable

[vonovak]

Hello and thanks for the PR,
I can't comment much on the implementation, as it was done by someone else, but "UTC timestamp" is an odd expression - timestamp is a timezone-independent concept.

Can you please fill out "What's required for testing (prerequisites)?" and "What are the steps to reproduce (after prerequisites)?" so the fix can be properly verified by someone else?

Thank you

[mjmasn]

I just mean a timestamp equivalent to the user-selected date at 00:00:00.000Z, which refers to the previous day in timezones behind UTC (e.g. anything in USA)

Repro steps:

1. Add a date/time picker to your app with the design="material" prop (there's other setup to make material pickers work IIRC, I guess follow the documentation...)
2. Run the app in android on a device or emulator set to PST timezone (or any behind-UTC timezone)
3. Select a date and time
4. Returned day of month is 1 day behind your selection, but with the correct local time.

The only workaround is to select the wrong date initially, which users understandably aren't too keen on.

The fix is reading the timestamp from the material date picker as UTC then extracting the UTC year/month/day of month and setting those values back onto the local time so that the day of month the user picks is the one selected, regardless of the user's timezone offset from UTC.

It seems the author assumed the timestamp returned was midnight in the local time on the selected date, which was probably a fair assumption if the old style picker worked that way, but unfortunately this is not the case with the material picker.

We've patched this in our app already and it's now working correctly, but hopefully this helps anyone else who has encountered the same issue.