Problem
If the device timezone changes while the app is running, Calendar keeps sending the old timezone to the server. The fix only takes effect once the Calendar view model is recreated, for example by relaunching the app. Releases are grouped into days by the old zone, so timed releases near midnight can land on the wrong day or in the wrong week. Meanwhile Today and the air times follow the new zone, so the screen can mix the two. 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. This is the Android counterpart of silo-apple #516.
Source evidence
At silo-android 86e1ebc7 (phone, tablet and TV share the view model):
androidApp/.../di/AndroidModule.kt:443 and androidTvApp/.../di/AndroidTvModule.kt:416: timezoneId = java.util.TimeZone.getDefault().id is read once, when the view model is created.shared/.../viewmodel/CalendarViewModel.kt:85,200: it is stored as a constructor val and sent as timezone on every fetch, including pull-to-refresh.- The view model comes from
koinViewModel() (CalendarScreen.kt, TvCalendarScreen.kt) and survives backgrounding while its back-stack entry exists.
todayProvider = { LocalDate.now().toString() } is evaluated on each load, and CalendarTimeFormatter uses ZoneId.systemDefault() per call. Today and air times therefore follow the new zone, while the server's day grouping doesn't.CalendarViewModel.kt:90-96: the cache key is (weekStart, filter, libraryId), with no timezone.- There is no
ACTION_TIMEZONE_CHANGED receiver in the repo.
Expected behavior
After a timezone change, Calendar sends the new timezone, refetches the visible week, recomputes Today in the new zone, and doesn't reuse a response cached for the old zone. For example: read TimeZone.getDefault().id (or ZoneId.systemDefault()) for each request instead of injecting it once, include it in the cache key, and refresh on ACTION_TIMEZONE_CHANGED or on resume. The web client already includes the timezone in its query key (silo-server web/src/hooks/queries/keys.ts).
Validation
Related to silo-android #314 (Calendar — Android) and #313 (Calendar — Android TV); parent silo-server #1134 AC2 and X3 (dates across timezones). Not marked as blocking (maintainer decision): relaunching the app gives correct dates.
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 sending the old timezone to the server. The fix only takes effect once the Calendar view model is recreated, for example by relaunching the app. Releases are grouped into days by the old zone, so timed releases near midnight can land on the wrong day or in the wrong week. Meanwhile Today and the air times follow the new zone, so the screen can mix the two. 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. This is the Android counterpart of silo-apple #516.
Source evidence
At silo-android
86e1ebc7(phone, tablet and TV share the view model):androidApp/.../di/AndroidModule.kt:443andandroidTvApp/.../di/AndroidTvModule.kt:416:timezoneId = java.util.TimeZone.getDefault().idis read once, when the view model is created.shared/.../viewmodel/CalendarViewModel.kt:85,200: it is stored as a constructorvaland sent astimezoneon every fetch, including pull-to-refresh.koinViewModel()(CalendarScreen.kt,TvCalendarScreen.kt) and survives backgrounding while its back-stack entry exists.todayProvider = { LocalDate.now().toString() }is evaluated on each load, andCalendarTimeFormatterusesZoneId.systemDefault()per call. Today and air times therefore follow the new zone, while the server's day grouping doesn't.CalendarViewModel.kt:90-96: the cache key is(weekStart, filter, libraryId), with no timezone.ACTION_TIMEZONE_CHANGEDreceiver in the repo.Expected behavior
After a timezone change, Calendar sends the new timezone, refetches the visible week, recomputes Today in the new zone, and doesn't reuse a response cached for the old zone. For example: read
TimeZone.getDefault().id(orZoneId.systemDefault()) for each request instead of injecting it once, include it in the cache key, and refresh onACTION_TIMEZONE_CHANGEDor on resume. The web client already includes the timezone in its query key (silo-serverweb/src/hooks/queries/keys.ts).Validation
Related to silo-android #314 (Calendar — Android) and #313 (Calendar — Android TV); parent silo-server #1134 AC2 and X3 (dates across timezones). Not marked as blocking (maintainer decision): relaunching the app gives correct dates.
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.