There have been issues surrounding the way dates are stored and displayed in the UI for months now. The main issue is that the UI has been submitting UTC dates to the API and we are storing said dates as UTC in the database, but have historically been displaying dates in local time. We keep the UI and DB in UTC because we are only really concerned with the date and not the time. This setup is slightly unorthodox in that you usually don't do so with a DateTime type. The column in the DB should be a Date only, but sadly it is of type DateTime and I think fixing that is beyond the scope of this patch.
The PR does the following:
Update SuperForms to V2
Fixes some UI bugs that blocked using local dates in a date picker
Fix date pickers
Now use local date in the UI
Remove any time value from the underlying date object to avoid confusion
Dates in UI rendering now all use UTC
And some other bug fixes packaged in:
TrainingProgramScheduledSlot modal now invalidates data
JournalEntry now invalidates correct data
Updated prettier
So after the PR, the flow is as follows:
SuperForms defaults() creates a new default date in "local time" using new Date()
DateField component removes time value in local time, and is edited in local time
Form is submitted with date in UTC (this is the quirk that caused confusion for me...)
This is because the form will convert the value to a string of format YYYY-MM-DD and when ingested to create the JSON post data this ends up being YYYY-MM-DDT00:00:00.000 in UTC
There have been issues surrounding the way dates are stored and displayed in the UI for months now. The main issue is that the UI has been submitting UTC dates to the API and we are storing said dates as UTC in the database, but have historically been displaying dates in local time. We keep the UI and DB in UTC because we are only really concerned with the date and not the time. This setup is slightly unorthodox in that you usually don't do so with a
DateTimetype. The column in the DB should be a Date only, but sadly it is of type DateTime and I think fixing that is beyond the scope of this patch.The PR does the following:
And some other bug fixes packaged in:
TrainingProgramScheduledSlotmodal now invalidates dataJournalEntrynow invalidates correct dataSo after the PR, the flow is as follows:
defaults()creates a new default date in "local time" usingnew Date()DateFieldcomponent removes time value in local time, and is edited in local timeYYYY-MM-DDand when ingested to create the JSON post data this ends up beingYYYY-MM-DDT00:00:00.000in UTC