search

tom-james-watson / breaktimer-app

Manage periodic breaks. Avoid eye-strain and RSI.
https://breaktimer.app
GNU General Public License v3.0
1.07k stars 80 forks source link

Break timings get messed up when user changes time zone #215

Open JWaldenback opened 1 year ago

JWaldenback commented 1 year ago

Describe the bug when the windows break timer changes the break frequency, break duration and snooze duration by itself they are often changed to something ridiculous like 21 hours and 55 minutes. it's always just the hour part that is changed, not the minute part

image

To Reproduce i'm not entirely sure how to reproduce this issue but it has happened for me multiple times. possibly it could be related to that the computer keeps running when locked and it tampers with the break time for some reason

JWaldenback commented 1 year ago

no other settings are changed. only those three (and just the hour part)

patrickjohncollins commented 1 year ago

Did you perhaps change travel and change time zones? I feel that this problem occurred when I travelled from Atlantic to Pacific coast. But maybe not.

JWaldenback commented 1 year ago

in fact, this time I did. but it has happened multiple times before when I have not switched time zones. so it can't only be related to that

patrickjohncollins commented 1 year ago

I've been flying around the world these past few months, every time I change time zones the break frequency, break length and snooze length are offset by the number of hours difference between origin and destination. There is certainly a bug here. Am I the only one to experience this?

patrickjohncollins commented 1 year ago

I should mention I'm running Windows 11 Pro, perhaps this problem doesn't occur on Mac / Linux.

Jardo-51 commented 1 year ago

I also have this problem on Linux (Ubuntu).

Jardo-51 commented 1 year ago

Perhaps the issue is caused not only by switching time zones but also by switching to/from daylight savings time.

torpesco commented 1 year ago

I'm on build 1.2.0 on macOS Ventura 13.5 (22G74).

I started noticing this issue frequently in the past few weeks. Not sure exactly when (I've had some vacation time and travel mixed in).

I can't remember if it happened before I travelled (across time zones). Whatever the case, I've fixed the duration settings a few times and within a day they've returned to random large values. All the times for break frequency & length and snooze length get changed.

For some reason I didn't bother getting a screen shot or anything. If it happens again, is there any specific info (log file, etc) that I should gather?

torpesco commented 1 year ago

Maybe it is time zone related, or at least that must be one factor. The first times I noticed the issue I had to fix the duration settings a few times, but they were fine after my note last week.

I flew yesterday and the frequency & length settings are off again. They were all increased by an even 21 hours. The first time I had this happen, the changes looks much more random, so maybe there are a couple possible causes?

The work day schedule also shifted with the time zone change, but that matched the difference between time zones.

Screenshot 2023-08-28 at 10 17 37
atdr commented 10 months ago

I've also had this issue repeatedly across Windows 10, 11 and macOS Ventura (13.6). Not sure what's causing it, but will monitor more closely from now on to see whether it's related to time zone / system time changes as suggested in the thread

roijalbaker commented 9 months ago

It is for sure the change of time zone / system time. I travel with my laptop (MacOS) and every time I'm in a new timezone the settings seem to be pretty random. I'm now so much used to it that whenever I change timezone, the first thing I do is update the break timer settings...

f3k-freek commented 7 months ago

I experienced the same after travelling to a different timezone. Apple Silicon MacOS Sonoma 14.4.1. In my case also the minutes and seconds changed. For bothe break settings and Work hours.

focustense commented 6 months ago

This is probably because all the relevant settings are stored as a Date, and not normalized to UTC. After changing the time zone or switching DST setting, the dates will deserialize in the local time zone which has a different hour component. Technically it is the same date, but only if you take into account the time zone offset.

Simplest solution would be to strictly use getUTCHours and other UTC APIs so that the values aren't affected by time zone. Better (IMO) would be not to use Date at all (except for the Moment used to schedule the next break) and instead use Typed Duration, or a similar library, or just store the number of seconds.