app: fix wallet birthday is UTC date #2236
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
chappjc
force-pushed
the
ui-wallet-bday-local
branch
3 times, most recently
from
74fe56d
to
a538357
Compare
|
Seems to be working as expected, but I'm going to try again in a couple hours when it's tomorrow in GMT. |
|
No longer getting a future date when it's tomorrow in GMT but not locally. Wallet backend gets the right date as well, logged as |
JoeGruffins
approved these changes
Mar 22, 2023
Yeah, sorta intended. @martonp would probably be most familiar with the logic, but that may 27, 2022 day is the default birthday under certain conditions. Perhaps the workflow you described of switching wallet types evades the logic that detects the "is seeded" check that should use a more recent time. |
When using a <input type='date'> element, it is tricky to get the time zone correct when using the value, valueAsNumber, and valueAsDate fields. This is because the browser will always display the date as UTC, regardless of how you have set valueAsDate. Also, when getting the date out with new Date(input.value), where the value is yyyy-mm-dd, the Date parses as in UTC. When the user is interacting with the input element, they are thinking in local time. However, unless we offset the time that we set, it can show an incorrect date. This change sets the value date string manually to the local date. We could also offsets the Date that we assign to valueAsDate so that it will show a local date, or similarly with valueAsNumber, but this is harder to follow and we do not benefit from finer precision that simply 12am of the current day. When reading the selected date back into javascript, we also have to interpret it as a local date string. We do this by forcing the Date constructor to interpret the date as local by appending "T00:00" to the date string from input.value. We also must use this trick when reading the min and max date strings. We could instead use valueAsDate and manually shift in the opposite direction as when we set it, but this seems better.
chappjc
force-pushed
the
ui-wallet-bday-local
branch
from
a538357
to
4a0abeb
Compare
buck54321
approved these changes
Mar 24, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #2192
When using a
<input type='date'>element, it is tricky to get the time zone correct when using thevalue,valueAsNumber, andvalueAsDatefields. This is because the browser will always display the date as UTC, regardless of how you have setvalueAsDate. Also, when getting the date out withnew Date(input.value), where the value isyyyy-mm-dd, theDateparses as in UTC (12am UTC instead of local).When the user is interacting with the input element, they are thinking in local time. However, unless we offset the time that we set, it can show an incorrect date. This change sets the
valuedate string manually to the local date. We could also offset theDatethat we assign tovalueAsDateso that it will show a local date, or similarly withvalueAsNumber, but this is harder to follow and we do not benefit from finer precision than simply 12am of the current day.When reading the selected date back into javascript, we also have to interpret it as a local date string. We do this by forcing the
Dateconstructor to interpret the date as local by appending"T00:00"to the date string frominput.value. We also must use this trick when reading theminandmaxdate strings. We could instead usevalueAsDateand manually shift in the opposite direction as when we set it, but this seems better.See https://dev.to/mendyberger/input-and-js-dates-2lhc for a better explanation