You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When you have alarm set at 8:00 on Mondays and you experience a DST change (CEST->CET in my case) during the week, the alarm goes off at 7:00 on the next Monday. (And then also on 8:00)
To Reproduce
Steps to reproduce the behavior:
Set an recurring alarm at 8:00.
Experience DST change before the alarm.
The alarm goes off at the "original 8:00", which is in the old timezone.
The alarm additionally goes off at the "new 8:00" (presumably because when Chrono checks for the closest 8:00, it is still today, because now it uses the new timezone).
Expected behavior
A single alarm goes off at the expected time (8:00).
Smartphone Information
Device: Poco F4
OS: Android 13
App version 0.6.0-beta1
Additional context
It seems Chrono schedules next alarm using the timezone that is active during the "scheduling" and does not take into consideration that it could have changed in the meantime.
The text was updated successfully, but these errors were encountered:
Same here. I think the alarms might be internally set with the system as relative offsets from when they're saved or the last one occurred, and would need to be updated whenever the clock time changes. I suspect this would also happen if traveling between time zones, or if the phone has been in airplane mode for a while and has to resync to network/carrier time after airplane mode is turned off.
Describe the bug
When you have alarm set at 8:00 on Mondays and you experience a DST change (CEST->CET in my case) during the week, the alarm goes off at 7:00 on the next Monday. (And then also on 8:00)
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A single alarm goes off at the expected time (8:00).
Smartphone Information
Additional context
It seems Chrono schedules next alarm using the timezone that is active during the "scheduling" and does not take into consideration that it could have changed in the meantime.
The text was updated successfully, but these errors were encountered: