| Summary: | Night color shifting happens at the wrong time during daylight savings time when using manual Date & Time setting | ||
|---|---|---|---|
| Product: | [Applications] systemsettings | Reporter: | Silviu C. <silviucc> |
| Component: | kcm_nightcolor | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bharadwaj.raju777, bizyaev, ddascalescu+kde, dellfirmware, fahimshahriar188, holyzolly, igarcia, jvanh1983, kwin-bugs-null, kwizzz, m.schalks, miranda, natalie_clarius, nate, qwe2968, teohhanhui, wuda25 |
| Priority: | HI | ||
| Version: | 5.27.5 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/plasma-workspace/-/commit/b8544fc070e88614feb9c198f6ea910c91f3c5d5 | Version Fixed In: | 5.27.10 |
| Sentry Crash Report: | |||
| Attachments: |
Screenshot illustrating the problem
Screencast of Night Color not working |
||
Are the latitude and longitude that it reports accurate for your real location? Have you by any chance changed your timezone recently? If you turn off Night color in System Settings and turn it back on again, does it work? (In reply to Nate Graham from comment #1) > Are the latitude and longitude that it reports accurate for your real > location? > > Have you by any chance changed your timezone recently? > > If you turn off Night color in System Settings and turn it back on again, > does it work? Detected latitude and longitude are accurate. I did not change time zone. Turning it off and on again does not fix the problem. All right, thanks. Not sure how to proceed here. (In reply to Nate Graham from comment #3) > All right, thanks. Not sure how to proceed here. Just a thought... Is the code responsible for doing the colour shifting trying to do any other type of math like figuring timezones and such? When it seems to me like it's not looking at the actual system time but something else. In my case the system clock is actually set to local time. So what is shown in the time applet from the taskbar matches what the UEFI would show. Could this be a duplicate of https://bugs.kde.org/show_bug.cgi?id=468295? Same problem here! When I set "Sunset and sunrise at manual location", it works perfectly. The problem is only with "Sunset and sunrise at current location". Here're the screenshots: https://ibb.co/6Pv1HMK https://ibb.co/17JPrbX (In reply to Nate Graham from comment #3) > All right, thanks. Not sure how to proceed here. Please see also https://bugs.kde.org/show_bug.cgi?id=471639 and https://www.youtube.com/watch?v=Ro2C9oM-j_s&t=773s at 10:30 Only manual setting works fine. Can you please paste the output of running `qdbus org.kde.KWin /ColorCorrect GetAll org.kde.kwin.ColorCorrect` in a terminal window when the screen color temperature is incorrect? Please also specify the expected screen temperature. Thanks! igarcia@meowfiesta:~ $ date Mon Jul 31 02:24:36 PM EDT 2023 igarcia@meowfiesta:~ $ qdbus org.kde.KWin /ColorCorrect GetAll org.kde.kwin.ColorCorrect available: true currentTemperature: 5000 enabled: true inhibited: false mode: 0 previousTransitionDateTime: 1690826346 previousTransitionDuration: 2023264 running: true scheduledTransitionDateTime: 1690868534 scheduledTransitionDuration: 2020380 targetTemperature: 4500 As you can see it is changing to night light, even though it is only 2:24 PM. Time and timezone are set correctly. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! (In reply to Nate Graham from comment #8) > Can you please paste the output of running `qdbus org.kde.KWin /ColorCorrect > GetAll org.kde.kwin.ColorCorrect` in a terminal window when the screen color > temperature is incorrect? Please also specify the expected screen > temperature. Thanks! Info attached, thanks! Thanks! Created attachment 161806 [details]
Screencast of Night Color not working
I have the same problem and I've attached a narrated screencast.
Today 50 minutes after when Night color should've kicked in, I noticed I also had "Set date and time automatically" unchecked. When I checked it, Night color kicked in.
Operating System: Fedora Linux 38
KDE Plasma Version: 5.27.8
KDE Frameworks Version: 5.109.0
Qt Version: 5.15.10
Kernel Version: 6.4.15-200.fc38.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 20 × 12th Gen Intel® Core™ i7-12700H
Memory: 62.5 GiB of RAM
Graphics Processor: Mesa Intel® Graphics
Manufacturer: TUXEDO
Silviu, is that the case for you as well, that you have automatic date & time turned off? If not, then Dan's issue is something else and will need a new bug report to track it. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! (In reply to Nate Graham from comment #14) > Silviu, is that the case for you as well, that you have automatic date & > time turned off? > > If not, then Dan's issue is something else and will need a new bug report to > track it. Hello, unfortunately I'm not using the KDE version of Opensuse so I can't test it. So you switched away from KDE since submitting this bug report? (In reply to Nate Graham from comment #17) > So you switched away from KDE since submitting this bug report? Yes. (In reply to Nate Graham from comment #17) > So you switched away from KDE since submitting this bug report? This bug is present on Fedora 38 KDE as well. I can also confirm for F38 and openSUSE Leap 15.5. My suspicion is that this is related to daylight savings, as the full night color level is reached exactly 1 hour later (KDE's systemwide time zone is Berlin (i.e. CEST, UTC+2 at the moment)). (Another suspicion is that it could be related to time in BIOS being not set to UTC...) Sounds like it. Again, for everyone experiencing this issue, do you have "Set date and time automatically" unchecked in Date & Time? And if so, does it start working of you turn that feature on? *** Bug 475000 has been marked as a duplicate of this bug. *** > do you have "Set date and time automatically" unchecked in Date & Time? And if so, does it start working of you turn that feature on?
Since I've checked that, Night color shifting has been behaving as expected.
Thanks, I suspected as much. So is your clock also wrong by an hour? (In reply to Nate Graham from comment #21) > Again, for everyone experiencing this issue, do you have "Set date and time > automatically" unchecked in Date & Time? And if so, does it start working of > you turn that feature on? Quick status report: * openSUSE Leap 15.5: setting was disabled; I turned this feature on * F38: setting was enabled; I turned it off (next step is to turn it on again; maybe turning it off and on again solves things?) * on both laptops, BIOS time is set to UTC (so 2 hours off to CEST) Unfortunately, testing is annoying, as I didn't have the chance to sit in front of my systems at the time when night light is kicking in. * Leap 15.5 having automatic time sync on: night light still 1 hour off * F38 with automatic date & time turn on again: 1 hour off => no change In that case I think your issue is probably something different, as turning on automatic time sync worked for Dan. Dan, was your clock wrong by 1 hour while automatic time sync was turned off? I think that there's more to it than daylight savings. Today, I missed the time when night color kicked in (start: 18:06; fully changed by 18:56) and jumped in too late: I woke up both my laptops from sleep around 19:36, which would mean that either full night light (if working as expected) or transition phase to night light (if it's a 1h off issue). But both my laptops had no night color enabled (i.e. icon was not active and color at 6,500K), which contradicts the 1h off theory. However, the night color kicked in about 1-2 minutes after waking up (icon became active in task bar), starting with day color temperatur default of 6,500K and gradually working down to 4,500K (default for night color temperature) which got reached at 20:10. Could it be that night color still decides to gradually go down to night color temperature if invoked close to the temperature change time frame? Is there some way to increase logging for night color control? (In reply to Nate Graham from comment #27) > In that case I think your issue is probably something different, as turning > on automatic time sync worked for Dan. > > Dan, was your clock wrong by 1 hour while automatic time sync was turned off? The clock was correct. I did change timezones a couple times over the course of a month, but I had set it manually as soon as I landed. If you had automatic time sync turned off, and night color was wrong by exactly the amount of time that the system time was incorrect by, but the clock showed the correct time, that's extremely weird. Since Silviu C is no longer able to reproduce the bug due to having stopped using Plasma, and the issue is now fixed for Dan, we can make this bug report about your issue, Kwizzz. Are you using automatic location? If so, and if setting the location manually to the correct time fixes it, then it sounds like Bug 471639 is a duplicate of this one. Cool. Here are my steps to reproduce this: * Select "Sunset and sunrise at current location" -> night light does not kick in at that displayed time * Note down the calculated times (in my case: night light starts at 18:03 and is fully changed at 18:55) and current location (latitude/longitude; and yes: it is correct) for the next two steps * Select "Sunset and sunrise at manual location" and type in the location from above and -> the same times are displayed and this time the night light is kicking in correctly * Next use the times from first step and type them in under "Custom times" -> night light starts exactly at the times specified So, everything works well, except if I chose "Sunset and sunrise at current location": night light is delayed (kicking in at exactly 19:37 and fully changed (4,500K) at exactly 20:10; interesting: these times have always been the same, despite the calculated ones jumping around 18:01-18:03) Regional settings: (Date and time displayed correctly.) * Region & Language: American English * Date & Time: ** Date and Time: Set date and time automatically selected (but no difference if enabled or not) ** Time Zone: Europe/Berlin (LMT) Is it the case that the time that it says would be sunset is correct but it only actually kicks in one hour after it's dark, or does it display a wrong time for when it should be sunset at your location but the actual effect is aligned with the sun hours? (In reply to Natalie Clarius from comment #32) > Is it the case that the time that it says would be sunset is correct but it > only actually kicks in one hour after it's dark, or does it display a wrong > time for when it should be sunset at your location but the actual effect is > aligned with the sun hours? it shows the correct sunset time( when night color supposed to kick in) but at least for me it kicks in at 2PM EST even though it detects the coordinates and calculates the time correctly (18:37 EST, full transition 19:20 EST). teohhanhui@Han-MacBook-Air:~$ date Sun 29 Oct 2023 11:21:10 AM +08 teohhanhui@Han-MacBook-Air:~$ qdbus org.kde.KWin /ColorCorrect GetAll org.kde.kwin.ColorCorrect available: true currentTemperature: 3000 enabled: true inhibited: false mode: 0 previousTransitionDateTime: 1698428204 previousTransitionDuration: 1970526 running: true scheduledTransitionDateTime: 1698556814 scheduledTransitionDuration: 1973224 targetTemperature: 3000 As others have mentioned, the displayed transition start/end times are correct, and everything works fine when using manual location with the same displayed coordinates. Thanks for that hint. I think I nailed it down a bit while fooling around at the DBus level.
All times are displayed correctly via qdbus with manual location and manual time (night color kicking in currently around 16:48)...
...but having set automatic location, I get that strange 18:37 again:
$ qdbus org.kde.KWin /ColorCorrect GetAll org.kde.kwin.ColorCorrect | awk '/Time/ {print $1, strftime("%T", $2)}'
previousTransitionDateTime: 18:36:38
scheduledTransitionDateTime: 06:20:07
If I force automatic recalculation to my current location, things look great
$ qdbus org.kde.KWin /ColorCorrect nightColorAutoLocationUpdate 50 9
$ qdbus org.kde.KWin /ColorCorrect GetAll org.kde.kwin.ColorCorrect | awk '/Time/ {print $1, strftime("%T", $2)}'
previousTransitionDateTime: 16:48:07
scheduledTransitionDateTime: 06:38:28
My guess is that auto location coordinates are not handed over correctly to sunset/sunrise calculation, so it falls back to lat 0, long 0
$ qdbus org.kde.KWin /ColorCorrect nightColorAutoLocationUpdate 0 0
$ qdbus org.kde.KWin /ColorCorrect GetAll org.kde.kwin.ColorCorrect | awk '/Time/ {print $1, strftime("%T", $2)}'
previousTransitionDateTime: 18:36:38
scheduledTransitionDateTime: 06:20:07
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3474 *** Bug 475161 has been marked as a duplicate of this bug. *** *** Bug 471639 has been marked as a duplicate of this bug. *** *** Bug 471238 has been marked as a duplicate of this bug. *** Git commit cb2b0e9c036d844d87fd104a3ae031b59243eaa5 by Ismael Asensio, on behalf of Sanjay Swain. Committed on 06/11/2023 at 20:03. Pushed by iasensio into branch 'master'. kcms/nightcolor: Fix nightcolor with automatic location As it turns out that the UI never send the geo-location to the backend so backend always fallbacks to (0, 0) lat and lon coordinates unless manually changed by `qdbus` commad.. I have tested the changes and it works as it should. FIXED-IN: 5.27.10 M +15 -0 kcms/nightcolor/ui/main.qml https://invent.kde.org/plasma/plasma-workspace/-/commit/cb2b0e9c036d844d87fd104a3ae031b59243eaa5 Git commit b8544fc070e88614feb9c198f6ea910c91f3c5d5 by Ismael Asensio. Committed on 06/11/2023 at 20:13. Pushed by iasensio into branch 'Plasma/5.27'. kcms/nightcolor: Fix nightcolor with automatic location As it turns out that the UI never send the geo-location to the backend so backend always fallbacks to (0, 0) lat and lon coordinates unless manually changed by `qdbus` commad.. FIXED-IN: 5.27.10 (cherry picked from commit cb2b0e9c036d844d87fd104a3ae031b59243eaa5) M +15 -0 kcms/nightcolor/package/contents/ui/main.qml https://invent.kde.org/plasma/plasma-workspace/-/commit/b8544fc070e88614feb9c198f6ea910c91f3c5d5 *** Bug 477057 has been marked as a duplicate of this bug. *** Glad to see a fix. Until it rolls out so I can test, I'd like to share that actually I'm still experiencing Night Color not changing even in the middle of the day (~3pm now), with "Set date and time automatically" checked. I've just checked and unchecked it, and Night Color still remained on. Operating System: Fedora Linux 38 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 Kernel Version: 6.5.6-200.fc38.x86_64 (64-bit) Graphics Platform: Wayland Processors: 20 × 12th Gen Intel® Core™ i7-12700H Product Name: TUXEDO InfinityBook Pro Gen7 (MK1) (In reply to Dan Dascalescu from comment #43) > Glad to see a fix. Until it rolls out so I can test, I'd like to share that > actually I'm still experiencing Night Color not changing even in the middle > of the day (~3pm now), with "Set date and time automatically" checked. I've > just checked and unchecked it, and Night Color still remained on. > > Operating System: Fedora Linux 38 > KDE Plasma Version: 5.27.8 > KDE Frameworks Version: 5.110.0 > Qt Version: 5.15.10 > Kernel Version: 6.5.6-200.fc38.x86_64 (64-bit) > Graphics Platform: Wayland > Processors: 20 × 12th Gen Intel® Core™ i7-12700H > Product Name: TUXEDO InfinityBook Pro Gen7 (MK1) Looks like it's fixed: https://bodhi.fedoraproject.org/updates/FEDORA-2023-78a7d98ec3 mentions upstream patch #2250757 which is https://bugzilla.redhat.com/show_bug.cgi?id=2250757 (F39 has it backported into 5.27.9.1-3, too, see https://bodhi.fedoraproject.org/updates/FEDORA-2023-059dfcf358) |
Created attachment 158929 [details] Screenshot illustrating the problem SUMMARY Night color shifting does not start at the correct time or end at the correct time . STEPS TO REPRODUCE 1. Go to System settings -> Display and monitor - > Night colour 2. At the option "Switching times:" select "Sunset and sunrise at current location" 3. Check that the geolocation is correct and that the proposed times for changing the colour temperature are correct (or just suited to what you'd like to happen). 4. Set the desired colour temperature. 5. Click on the "Apply button" OBSERVED RESULT The colour does not begin changing at the correct time despite what the taskbar applet shows. The next morning you may also find that despite it being way past the hour when night colour should have shifted back to daylight colour, your desktop will still have a red tint and the applet will show that night colour is still active EXPECTED RESULT Color shifting should begin and apply correctly at the advertised times SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20230512 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Kernel Version: 6.3.1-2-default (64-bit) Graphics Platform: Wayland Processors: 6 × Intel® Core™ i5-9600K CPU @ 3.70GHz Memory: 31,1 GiB of RAM Graphics Processor: AMD Radeon RX 6600 XT Manufacturer: Gigabyte Technology Co., Ltd. Product Name: Z390 GAMING X ADDITIONAL INFORMATION Attached screenshot that shows the functionality problem minus the red tint.