Times are offset

Question

Times are offset

SZanlongo opened this issue 6 years ago · 13 comments

It seems that the times are offset by an amount.

For example, setting sunset time to 9:00PM triggers at 5:00PM. This is consistent to the minute, so it looks like the time being used is a constant offset.

Answer 1 · 2019-05-14T23:15:11.000Z

Thanks for letting me know. What timezone are you in? Are the times still offset if you set the sunset time manually to your current time?

For example, say it's currently 5:30pm. If you switch the sunset time between 5:00pm and 6:00pm, does the theme change? Or does it only change if you switch between 9:00pm and 10:00pm?

Answer 2 · 2019-05-15T16:46:24.000Z

I'm currently in Eastern time. The theme changes like in your second example (9:00 vs 10:00).

Answer 3 · 2019-05-29T16:21:34.000Z

I'm also getting this issue in the EDT zone.

Answer 4 · 2019-06-06T10:58:00.000Z

I'm getting the same problem in IST. I get dark mode in the day and light mode at night. Seems as if the extension has a time zone preference.

Answer 5 · 2019-06-16T20:26:48.000Z

I have a similar issue but for me it has nothing to do with the time zone. It looks like the times are offset after the computer was in sleep mode. I suspect that the timer to switch the theme doesn't continue while the computer is in sleep mode.

Answer 6 · 2019-07-16T01:26:43.000Z

Thanks everybody, I uploaded 1.0.7 to addons.mozilla.org just now. It includes @abaco 's changes that will have the add-on check the time more frequently.

Please let me know if you continue to experience this bug with that version.

Answer 7 · 2019-07-16T17:17:31.000Z

Just an idea: could you guys (@SZanlongo, @tubbo, @devavret) check in the console of the developer tools that new Date() gives the same result as new Date(Date.now())? They should be the same. The extension currently uses the latter. The code is very simple and I can't see anything else that can go wrong... The problem must be somewhere in createDailyAlarm or convertToNextMilliEpoch.

Answer 8 · 2019-07-16T17:58:35.000Z

@abaco, the results are indeed the same.

Answer 9 · 2019-07-16T22:09:23.000Z

@SZanlongo, are they showing the correct time or the offset one? My best guess is that it's the correct time and the problem is somewhere else, but it would be great if you could check.

Answer 10 · 2019-07-16T22:59:31.000Z

It's actually wrong. I do have an explanation as to why (at least for my machine): Setting the privacy.resistFingerprinting flag to True disables canvas fingerprinting, which includes getting the correct timezone. If this flag is the cause for everyone, I'd suggest closing this issue since the cause is a conflicting user-side setting outside of your control.

Answer 11 · 2019-07-16T23:19:27.000Z

Interesting! I turned on the flag and I immediately started seeing the problem. I'll make a change to the readme to make this clear.

I can already think of some things that can be done to make it easier to set the time even if you have this flag set--such as being able to manually enter your timezone, or showing what the addon is picking up as the current time--but that would be something to consider in the future. #4 would also work if you'd be willing to use that.

In any case, if anyone experiences problem while the flag set to False, please let us know.

Answer 12 · 2019-07-16T23:34:42.000Z

Yes, a manual setting for the timezone is probably the way to go.

Answer 13 · 2019-07-17T00:32:01.000Z

I have a similar issue but for me it has nothing to do with the time zone. It looks like the times are offset after the computer was in sleep mode. I suspect that the timer to switch the theme doesn't continue while the computer is in sleep mode.

I can confirm that this part is fixed good enough by #6.