Enable Scheduling - Add TZ to page StartDate and EndDate #3919
+22
−3
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
GetPageDetails
API is called, which fails to specify theDateTimeKind
as 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
String
instead of a javascriptDate
object, 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).