Recurring events come back in the request's time zone, not their own

jcoffey-dev commented

2026-11-06 19:35:32 +00:00

Owner

A recurring event comes back in the time zone of the request instead of its own. One-off events are fine.

To reproduce on 27.1-rc.9: create a weekly event with start 2026-01-05T18:00:00 and timeZone Etc/UTC, then CalendarEvent/get it with timeZone: America/Phoenix. It comes back with utcStart 01:00Z and timeZone America/Phoenix, so 18:00 Phoenix time instead of 11:00. The master does it, and so do the occurrences from CalendarEvent/query with expandRecurrences. The same thing without a recurrence rule comes back correctly at 18:00Z.

So anyone whose event was created in another zone sees the series at the wrong time in the webmail and console calendars, and in the new event search.

It looks like the request time zone is passed straight into the expansion: .expand(default_tz, ...) in crates/jmap/src/calendar_event/query.rs, and expand_from_ids / expand_single in get.rs. It should only be the fallback for floating events. It was already there in 0.16.27, before we forked, and upstream fixed it in 1.0. Found while testing event search for coffey-labs/ihasmail#69.

A recurring event comes back in the time zone of the request instead of its own. One-off events are fine. To reproduce on 27.1-rc.9: create a weekly event with `start` 2026-01-05T18:00:00 and `timeZone` Etc/UTC, then `CalendarEvent/get` it with `timeZone: America/Phoenix`. It comes back with `utcStart` 01:00Z and `timeZone` America/Phoenix, so 18:00 Phoenix time instead of 11:00. The master does it, and so do the occurrences from `CalendarEvent/query` with `expandRecurrences`. The same thing without a recurrence rule comes back correctly at 18:00Z. So anyone whose event was created in another zone sees the series at the wrong time in the webmail and console calendars, and in the new event search. It looks like the request time zone is passed straight into the expansion: `.expand(default_tz, ...)` in `crates/jmap/src/calendar_event/query.rs`, and `expand_from_ids` / `expand_single` in `get.rs`. It should only be the fallback for floating events. It was already there in 0.16.27, before we forked, and upstream fixed it in 1.0. Found while testing event search for coffey-labs/ihasmail#69.

jcoffey-dev added the bug

priority

p2

labels 2026-11-06 19:35:32 +00:00

jcoffey-dev referenced this issue from a commit

2026-11-06 20:11:55 +00:00

Calendar: keep the UTC zone of a series that starts in UTC

jcoffey-dev referenced a pull request that will close this issue

2026-11-06 20:12:04 +00:00

Calendar: keep the UTC zone of a series that starts in UTC #305

jcoffey-dev self-assigned this 2026-11-06 20:23:46 +00:00

jcoffey-dev closed this issue

2026-11-06 20:27:41 +00:00

jcoffey-dev commented

2026-11-06 20:28:24 +00:00

Author

Owner

Fixed in #305. It turned out narrower than I wrote above: only series whose start is stored in UTC were affected (which is what a JMAP timeZone: Etc/UTC event becomes). Series in a named zone, floating series and one-off events were already fine.

Events already stored the old way read correctly too, no reindex needed. It'll be in the next release.

Fixed in #305. It turned out narrower than I wrote above: only series whose start is stored in UTC were affected (which is what a JMAP `timeZone: Etc/UTC` event becomes). Series in a named zone, floating series and one-off events were already fine. Events already stored the old way read correctly too, no reindex needed. It'll be in the next release.

jcoffey-dev referenced a pull request that will close this issue

2026-11-06 22:35:31 +00:00

Version 27.1-rc.11 #307

jcoffey-dev commented

2026-11-06 23:32:37 +00:00

Author

Owner

Fixed in #305, released in 27.1-rc.11. A recurring event that starts in UTC now keeps that zone, for the series and its occurrences, whatever zone the request uses. Series stored before the fix read correctly too, with no reindex.

Recurring events come back in the request's time zone, not their own #303