With the calendar time-zone setting away from the device zone, the
event and task editors showed device-local times but saved them
labelled with the calendar zone, so opening an event and saving it
unchanged moved it by the difference between the two zones.
The calendar now works in display dates like the webmail
(`toDisplayDate` / `fromDisplayDate`): Dates whose local fields read
as the wall clock in the calendar zone. They are the identity while
the calendar follows the device.
- `getEventStartDate` / `getEventEndDate` return display dates, so the
views, the detail sheet and the editor show calendar-zone times
- the editors convert back through `eventTimeFieldsToSave` and
`buildTaskEditorChanges`: a start, end or due the user left alone is
saved exactly as stored, a changed one is converted into the zone the
event or task lives in (new, floating and formerly all-day ones take
the calendar zone), and durations count whole days as calendar days
in that zone
- `getTaskDueDate` stays the real instant for reminders; the tasks
sheet uses `getTaskDueDisplayDate`, `displayNow` and
`isDisplayToday`
- wall clocks are parsed from their digits, so one inside the device's
own DST gap still converts right
- duplicating an event keeps its wall clock in its own zone instead of
reading the device time
Saving in the tasks sheet ran `onCreate`/`onUpdate` in a `try/finally`
without a `catch`, so a refused create or update became an unhandled
rejection: the spinner stopped, nothing was shown, and the user could
not tell whether the task was saved.
The editor state and the save logic move to `src/lib/task-editor.ts`.
`submitTaskEditor` returns the server's reason instead of throwing; the
sheet shows it in an alert and leaves the editor untouched so the input
can be fixed or saved again. It is cleared only after a successful save.
Linus Rath