Problem/Motivation
Dates saved with incorrect Timezone if User's timezone is different from the field value entered.
My site Timezone is set to America/Chicago.
Current User (Admin) Timezone is set to America/New York.
I have a recurring date field on an Event Content type.
I enter a date and time and set the timezone to America/Chicago.
The actual value in the database saves it to UTC, but as if it were America/New York tz not, America/Chicago.
I would expect if the timezone field is set, it should respect that setting. This seems to be the way the Simple Recurring Date Widget works.
Proposed resolution
Need to update DateRecurModularWidgetBase (I believe) to handle the correct timezone that is set on the field rather than the site or the user's timezone.
Remaining tasks
- Identify where the problem is (individual widgets or the Widget Base)
- Compare against the DateRecurBasicWidget
- (I Believe) simply update the DateRecurModularWidgetBase
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | 3074571-start-end-date-default-values.patch | 1.85 KB | dexiecarla |
| #10 | 3074571-form-values-loaded-invalid-test-only.patch | 1.39 KB | dpi |
| #4 | 3074571.patch | 13.08 KB | dpi |
| #4 | 3074571-test-only.patch | 11.81 KB | dpi |
| #9 | 3074571-form-values-loaded-invalid.patch | 3.07 KB | dpi |
Comments
Comment #2
pingevt commentedComment #3
dpiConfirmed issue.
Alpha widget is not adjusting user input to submitted time zone, instead it is UTC. Each widget does it a little differently, DR hijacks callback adding dateValueCallback to modify date_timezone live. Oscar creates date objects from raw user input.
Comment #4
dpiComment #7
dpiCommitted.
Thanks for the report.
Comment #8
dpiActually loading values from storage is still a little wacky.
Comment #9
dpiComment #10
dpiFixed test only patch, this should fail.
Comment #13
dpiCommitted with tests. 💎
Comment #15
dexiecarla commentedNot the best solution, but it works for me for now.
Site timezone is set to 'Australia/Melbourne'
When setting/editing date during early morning AEST, the date saved is always converted to UTC which is expected & understandable.
Let say, I set June 8 2022, saved date is June 7 2022
However when editing the content after its saved, the date in the calendar is June 7 2022 so its not converted to AEST or whatever timezone is set in that date.
Continuing to edit and save the content even not modifying the value of the date, it keeps saving the date in UTC timezone.
So this patch is just converting the saved date appropriate timezone in the UI.