time-based-themes icon indicating copy to clipboard operation
time-based-themes copied to clipboard

Published 20 hours ago • verified publisher icon skhzhang

Times are offset

Open 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.

SZanlongo avatar May 14 '19 21:05 SZanlongo

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?

skhzhang avatar May 14 '19 23:05 skhzhang

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

SZanlongo avatar May 15 '19 16:05 SZanlongo

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

tubbo avatar May 29 '19 16:05 tubbo

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.

devavret avatar Jun 06 '19 10:06 devavret

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.

zroug avatar Jun 16 '19 20:06 zroug

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.

skhzhang avatar Jul 16 '19 01:07 skhzhang

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.

abaco avatar Jul 16 '19 17:07 abaco

@abaco, the results are indeed the same.

SZanlongo avatar Jul 16 '19 17:07 SZanlongo

@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.

skhzhang avatar Jul 16 '19 22:07 skhzhang

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.

SZanlongo avatar Jul 16 '19 22:07 SZanlongo

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.

skhzhang avatar Jul 16 '19 23:07 skhzhang

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

SZanlongo avatar Jul 16 '19 23:07 SZanlongo

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.

zroug avatar Jul 17 '19 00:07 zroug