Enable Scheduling - Add TZ to page StartDate and EndDate #3919
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
daguiler
commented
Jul 17, 2020
| @@ -118,7 +118,10 @@ const PageService = function () { | |||
| const toFrontEndPage = function (pageResult) { | |||
| return { | |||
| ...pageResult.page, | |||
| schedulingEnabled: pageResult.page.startDate || pageResult.page.endDate, | |||
| schedulingEnabled: pageResult.page.startDate !== null || pageResult.page.endDate !== null, | |||
There was a problem hiding this comment.
This change was not strictly necessary, but React was complaining that schedulingEnabled was being assigned a string instead of a boolean value.
bdukes
approved these changes
Jul 17, 2020
mitchelsellers
approved these changes
Jul 18, 2020
3 tasks
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.
Fixes #3918
Summary
This is both a back-end issue and a front-end issue.
Initially, when start/end datetime is null, and the user picks a datetime in the date picker, the front-end sends the datetimes correctly as UTC, and the back-end API saves the datetimes correctly in the database as UTC.
Later, during browser refresh, the
GetPageDetailsAPI is called, which fails to specify theDateTimeKindas UTC when filling the DTO from the database, and therefore the datetimes are serialized back as local datetimes, which produces the offset in the front-end.At this point, if the user changes the datetime back to the original value, this time the date picker returns a
Stringinstead of a javascriptDateobject, and the TZ info is lost there, and the API then receives a local datetime. This sort of fixes the problem thereafter, but out of pure luck I would say.This pull request basically adds the lost TZ both in the back-end (by specifying the
DateTimeKind) and the front-end (using Date objects with the view model instead of strings).