Bug 489366

Summary:	Night Light with the "Custom times" option doesn't properly use custom times
Product:	[Applications] systemsettings	Reporter:	Tim Carr <tim>
Component:	kcm_nightcolor	Assignee:	Plasma Bugs List <plasma-bugs>
Status:	RESOLVED FIXED
Severity:	normal	CC:	bharadwaj.raju777, deadmeu, isma.af, kwin-bugs-null, miranda, natalie_clarius, nate
Priority:	NOR
Version:	6.1.1
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:	https://invent.kde.org/plasma/kwin/-/commit/6ef1c5dfbbb523eef3b9923af5d448a50079b9e6	Version Fixed In:	6.1.3
Sentry Crash Report:
Attachments:	example 1 (the night light is really disabled) example 2 (the night light is really enabled) example 3 (the night light is really enabled)

Description Tim Carr 2024-06-28 10:40:14 UTC

SUMMARY
On multiple systems using 6.1.1 (Wayland on both if it matters) I have night light set to use custom times. On one system night light was active (and changing the screen color) hours before it was scheduled to activate. Later on another system night light should have been active (with several hours to go before turning off) and I noticed it fading back to normal color, eventually disabling the effect before it should have been. In both instances the indicator caret in the settings panel was correctly where it should have been for the time of day, but the actual effect was not following properly.

STEPS TO REPRODUCE
1. Set Night Light's "Switching times" option to "Custom times".
2. Set some custom times (not sure if this is relevant, but both of my systems have non-default custom times).
3. Observe that the night light effect doesn't follow the times specified, or match the indicator in the settings kcm.

EXPECTED RESULT
Night light should follow the correct custom times. 

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 
Operating System: Linux
KDE Plasma Version: 6.1.1
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2

ADDITIONAL INFORMATION
 I didn't notice this issue prior to upgrading to 6.1.
 I didn't check on both, but the offset on one is about what my local time zone's offset is, and my hardware clock is in UTC, but every other clock on the system properly shows my local time.

Comment 1 Tim Carr 2024-07-02 02:18:17 UTC

Upon further investigation it seems that the "Custom times" option is working identically to the "Sunset/Sunrise at manual location". The offset that I thought looked tz related was just coincidence.

Comment 2 Miranda 2024-07-03 13:02:01 UTC

Confirmed.  Custom times no longer work since updating to 6.1.1.

Comment 3 Natalie Clarius 2024-07-03 13:47:10 UTC

I can't reproduce it, it's working fine for me.

Comment 4 deadmeu 2024-07-14 08:39:08 UTC

Created attachment 171651 [details]
example 1 (the night light is really disabled)

Comment 5 deadmeu 2024-07-14 08:39:25 UTC

Created attachment 171652 [details]
example 2 (the night light is really enabled)

Comment 6 deadmeu 2024-07-14 08:39:42 UTC

Created attachment 171653 [details]
example 3 (the night light is really enabled)

Comment 7 deadmeu 2024-07-14 08:43:03 UTC

Also an issue for me. 

The bug seems to show itself when the time ranges get flipped (assuming the current time is a little past 6pm and transition duration is set to 15 minutes):
1. if "Begin night light at" is set to 19:00, and "Begin day light at" is set to 18:00, then the night light will be disabled (GOOD)
2. if you drop the "Begin night light at" time to 17:00, the time range inverts and the night light is enabled (BAD)
3. if you bring the "Begin night light at" time back up to 19:00, and bump up the "Begin day light at" time to 20:00, the time range inverts and the night light is enabled (BAD)

See my the attached screenshots for examples of what I'm talking about. The day/night graph is rendered accurately according to the provided times, but the actual time the night light is being enabled differs from this graph, and although the graph says the night light should never be activated in any of these three scenarios, in reality the night light is being enabled in scenarios 2 and 3.

Comment 8 Vlad Zahorodnii 2024-07-15 09:50:36 UTC

What is the use case for creating such "flipped" custom times? On the kwin side, we have a guard to fallback to 6:00-18:00 cycle if such a configuration has been provided.

Comment 9 Vlad Zahorodnii 2024-07-15 09:51:27 UTC

Just in case, at the moment, the night light kcm is very permissive and allows setting configurations that kwin is going to reject. This one needs to be fixed.

Comment 10 Vlad Zahorodnii 2024-07-15 12:43:19 UTC

Git commit 2adf96246789c08266dcf01cf500094e1330dc82 by Vlad Zahorodnii.
Committed on 15/07/2024 at 12:16.
Pushed by vladz into branch 'master'.

plugins/nightlight: Relax custom times constraints

Apparently the night light kcm allows to set the custom times so the
evening is earlier than the morning to handle extreme cases close to
the North and the South pole.

NightLightManager::updateTransitionTimings() should require no changes.

M  +1    -5    src/plugins/nightlight/nightlightmanager.cpp

https://invent.kde.org/plasma/kwin/-/commit/2adf96246789c08266dcf01cf500094e1330dc82

Comment 11 Vlad Zahorodnii 2024-07-16 06:26:39 UTC

Git commit 6ef1c5dfbbb523eef3b9923af5d448a50079b9e6 by Vlad Zahorodnii.
Committed on 16/07/2024 at 06:26.
Pushed by vladz into branch 'Plasma/6.1'.

plugins/nightlight: Relax custom times constraints

Apparently the night light kcm allows to set the custom times so the
evening is earlier than the morning to handle extreme cases close to
the North and the South pole.

NightLightManager::updateTransitionTimings() should require no changes.
(cherry picked from commit 2adf96246789c08266dcf01cf500094e1330dc82)

M  +1    -5    src/plugins/nightlight/nightlightmanager.cpp

https://invent.kde.org/plasma/kwin/-/commit/6ef1c5dfbbb523eef3b9923af5d448a50079b9e6