Problem
If the device timezone changes while the app is running, Calendar keeps using the old timezone for its week boundaries and day keys until the app is force-quit. Meanwhile it sends the new timezone to the server. The request can then mix start/end dates from the old zone with the new timezone. Releases can land on the wrong day or drop out of the visible week, and the week strip's Today highlight can disagree with the week shown. This affects travellers, and anyone testing timezone cases by changing the device setting.
Found by source review while checking the Calendar documentation (siloserver.org PR #22); not yet reproduced on a device.
Source evidence
At silo-apple a63c511b (iPhone, iPad and Apple TV share this code):
Screens/Calendar/CalendarWeek.swift:11-15: private static let isoCalendar sets calendar.timeZone = .current once per process. It drives the week start, the days, the end and containsToday.Shared/DateFormatters.swift:9-16: the static isoDate formatter captures timeZone = .current once. It formats the start/end query dates and the day keys matched against the server's local_air_date.Screens/Calendar/CalendarViewModel.swift:111: the request sends TimeZone.current.identifier, read on every load, so it follows the new zone.CalendarViewModel.swift:15,17: week and selectedDay are set once when the view model is created; .task { load() } reloads the same week.CalendarWeekStrip.swift and CalendarView.swift highlight Today with Calendar.current.isDateInToday, which is live, and compare it against the frozen days.Networking/ResponseCache.swift:134-135: the cache key is calendar:<weekStart>:<filter>, with no timezone. A response for the old zone is shown first, until the refetch replaces it.- There is no observer for
UIApplication.significantTimeChangeNotification or NSSystemTimeZoneDidChange, and no use of TimeZone.autoupdatingCurrent.
Expected behavior
After a timezone change, Calendar recomputes the current week, the day keys and Today in the new zone. It sends matching start, end and timezone, and doesn't show a response cached for the old zone. For example: build the calendar and formatter with TimeZone.autoupdatingCurrent, or rebuild them on significantTimeChangeNotification, and include the timezone in the cache key. The web client already includes the timezone in its query key (silo-server web/src/hooks/queries/keys.ts).
Validation
Related to silo-apple #303 (Calendar — iOS) and #304 (Calendar — tvOS); parent silo-server #1134 AC2 and X3 (dates across timezones). Not marked as blocking (maintainer decision): relaunching the app gives correct dates. The Android counterpart is filed separately in silo-android.
AI-assisted: drafted with Claude Code (claude-opus-5-5) and GitHub CLI at the maintainer's direction. Found by source review only; not reproduced at runtime.
Problem
If the device timezone changes while the app is running, Calendar keeps using the old timezone for its week boundaries and day keys until the app is force-quit. Meanwhile it sends the new timezone to the server. The request can then mix
start/enddates from the old zone with the newtimezone. Releases can land on the wrong day or drop out of the visible week, and the week strip's Today highlight can disagree with the week shown. This affects travellers, and anyone testing timezone cases by changing the device setting.Found by source review while checking the Calendar documentation (siloserver.org PR #22); not yet reproduced on a device.
Source evidence
At silo-apple
a63c511b(iPhone, iPad and Apple TV share this code):Screens/Calendar/CalendarWeek.swift:11-15:private static let isoCalendarsetscalendar.timeZone = .currentonce per process. It drives the week start, the days, the end andcontainsToday.Shared/DateFormatters.swift:9-16: the staticisoDateformatter capturestimeZone = .currentonce. It formats thestart/endquery dates and the day keys matched against the server'slocal_air_date.Screens/Calendar/CalendarViewModel.swift:111: the request sendsTimeZone.current.identifier, read on every load, so it follows the new zone.CalendarViewModel.swift:15,17:weekandselectedDayare set once when the view model is created;.task { load() }reloads the same week.CalendarWeekStrip.swiftandCalendarView.swifthighlight Today withCalendar.current.isDateInToday, which is live, and compare it against the frozen days.Networking/ResponseCache.swift:134-135: the cache key iscalendar:<weekStart>:<filter>, with no timezone. A response for the old zone is shown first, until the refetch replaces it.UIApplication.significantTimeChangeNotificationorNSSystemTimeZoneDidChange, and no use ofTimeZone.autoupdatingCurrent.Expected behavior
After a timezone change, Calendar recomputes the current week, the day keys and Today in the new zone. It sends matching
start,endandtimezone, and doesn't show a response cached for the old zone. For example: build the calendar and formatter withTimeZone.autoupdatingCurrent, or rebuild them onsignificantTimeChangeNotification, and include the timezone in the cache key. The web client already includes the timezone in its query key (silo-serverweb/src/hooks/queries/keys.ts).Validation
Related to silo-apple #303 (Calendar — iOS) and #304 (Calendar — tvOS); parent silo-server #1134 AC2 and X3 (dates across timezones). Not marked as blocking (maintainer decision): relaunching the app gives correct dates. The Android counterpart is filed separately in silo-android.
AI-assisted: drafted with Claude Code (claude-opus-5-5) and GitHub CLI at the maintainer's direction. Found by source review only; not reproduced at runtime.