GNOME Bugzilla – Bug 778667
Night Light turned itself off one hour before sunrise
Last modified: 2017-07-06 15:18:22 UTC
gnome-settings-daemon 3.23.90-0ubuntu1 Ubuntu GNOME 17.04 Alpha, running GNOME Shell 3.22.4-1ubuntu1 I have automatic Night Light enabled. Today the Night Light suddenly transitioned to daylight mode at 6:07 am. But according to this chart, sunrise is at 7:07 am. https://www.timeanddate.com/sun/usa/bradenton Looking at the code, it looks like this off-by-one is intentional. Look for smear in https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/color/gsd-night-light.c I didn't see that until after I was almost done filing this bug. So maybe this will be NOTABUG, but I thought I'd at least ask about it.
gnome-settings-daemon-3.24.0-1.fc26 fedora 26 alpha, gnome-shell-3.24.0-1.fc26 Experienced the same behavior, Night light was turned off at 5:56am while in the settings it states the sunrise was expected at 6:56am.
I think this is a bug because it affects manual schedule as well. Also, it's only present on the exit transition from Night Light. For me there is no transition on the end side, it's just an immediate change. Could that be the issue? That it tries to transition out, but it fails and as a result it just suddenly changes an hour before?
*** Bug 782094 has been marked as a duplicate of this bug. ***
Created attachment 351257 [details] [review] Fixes this bug So I did some digging in the code and noticed some weird stuff. When the smearing mentioned above happens (for the hour before sunset/sunrise), a few things can happen: If we have a value that is not between 0 and 1, then we set the whole linear interpolation function then has "undefined behavior," as per the documentation[1]. It apparently returns about 4 billion, or whatever the "maximum" is described as in org.gnome.settings-daemon.plugins.color. If it's between 0 and 1 then we actually get normal values, since those two checks don't break everything. To fix this I simply added a check for whether 'factor' is negative. If so we take the inverse of it and use that for the function in the return statement. This way we get a smooth transition from the 'night' value up to the 'day' value of 6500k. [1]: https://developer.gnome.org/glib/stable/glib-Warnings-and-Assertions.html#g-return-val-if-fail
I confirm the problem in Solus GNOME 2017.04.18.0 64-bit. The last weekend just changed the time zone in my country and although the clock was updated automatically without problems, but now I must manually add 2 additional hours for night light to turn off at the expected time. On the other hand there is no transition and abrupt change of lighting is annoying.
Review of attachment 351257 [details] [review]: Does this still pass the self tests? I'm a bit confused why the factor should be outside 0..1.
Yes, it does pass the self tests. (For some reason the edid test was failing for me, but without that everything runs smoothly.) It doesn't matter if the value is greater than 1, the problem occurs when the value is negative: When we're going from 6500k to the user set temperature, the factor will be <1. If you look at the math that happens there in `night_light_recheck` you can see that the else-if statement will *always* return a negative if the math in the if statement checks out. This means that the assertion will fail and you'll get the undefined behavior mentioned in the docs every time we're going back to normal temperature. As it should always be positive for the changes being made, setting it to the positive value just makes the math work down the line.
Sorry, brain wasn't working. It's when you're going from the user defined temperature to 6500k that the factor will be negative.
*** Bug 784418 has been marked as a duplicate of this bug. ***
Created attachment 354905 [details] [review] color: Fix smearing out of Night Light effect The interpolation function expects factor values between 0. and 1., so we need to either pass the difference between current time and transition start, or between transition end and current time - not the difference between transition start and current time, which is always negative.
Review of attachment 354905 [details] [review]: makes sense
Attachment 354905 [details] pushed as 33481c5 - color: Fix smearing out of Night Light effect