Hello, I am willing to sponsor this fix with 150$USD via Paypal. The bug itself is reported here 469730 – Night color shifting happens at the wrong time during daylight savings time when using manual Date & Time setting. Acceptance criteria would be:
This bug has been affecting a large base of users and it would be nice to get it fixed. Please reach out for more info and if you’re interested. Thanks!
It seems like there are several different issues being described in the linked bug report, some observing a 1 hour delay during daylight savings and manual time setting and others shorter delays supposedly related to waking up from sleep. Could you describe again exactly what is the faulty behavior you’re observing that you would like to get fixed?
Hello,
Currently I am on EST timezone. Night color detects the coordinates and the sunset time accurately
However…instead of start changing color at the specific sunset time that it detected, it starts changing color at around 2PM EST, which does not make sense. If I set night color to ( sunset and sunrise at manual location) and put the coordinates that were detected correctly using ( sunset and sunrise at current location) night color works as expected and starts changing color at the expected time (18:30-19:27).
What’s your UTC offset? Are you on daylight saving EDT (UTC-4), as opposed to EST (UTC-5)?
If so, 2pm your time means 8pm my time (CEST (UTC+2)) which is kinda close to the time when my night color is activated (which is too late for my time zone).
My observation is that night light is kicking in at 19:37 (UTC+2) and fully changed (4,500K) at 20:10.
Can you double check if yours is kicking in at 1:37pm and is fully changed at 2:10pm?
Maybe night color completely ignores our current time and time zone and always starting at 17:37 and fully changed at 18:10 UTC.
yep, I can confirm mine is kicking in at 1:37pm EST and is fully changed at 2:10pm EST. I think you assessment about ignoring current time and time zone may be accurate.
Du you know where the source code for night color settings is?
I have made a merge request which hopefully should fix the issue… Considering the actual code changes needed I really want to die in a corner given how much time I have spent on it 
Anyway I tested the patch and it seems to be working. I have checked qdbus6 org.kde.KWin /ColorCorrect GetAll org.kde.kwin.ColorCorrect | awk '/Time/ {print $1, strftime("%T", $2)}'
And it returns night light starting time at around 5:30PM IST. Before it used to say night light starts around midnight.
Kudos!
This was my first time to look at KDE/Qt code. Wasn’t able to figure out how things are related to each other (especially how QML invokes dataengine code) or how to debug or compile and test.
Looks rather tricky to code for KDE…
You want to share how you learned and approach this?
Yeah definitely.
So after checking through the bug report I thought that there is an issue in backend code which gives UTC time instead of local time and thus creating this bug. So I looked into the KWin repository (it’s where the backend of nightcolor or most settings lies, the code is in src/plugins/nightcolor folder of KWin) and checked the implementation of the algorithm and verified inputs and outputs are correct but I couldn’t find anything wrong.
You don’t actually need to understand everything here in the implementation (I still don’t). When dealing with this kind of bugs Just look for whether the inputs the function is recieving is correct or not. A lot of the time it’s where the problem lies.
So after I couldn’t find anything there I looked into the plasma workspace UI files to see that if the UI is properly sending the data to the backend or not and sure enough there is the issue. The coordinates and time both are calculated but are not sent to the backend. So this causes UI to display correctly but the backend fallback to coordinate (0,0) and night light kicks in at wrong time.
Thank you! bounty has been paid. Thank you all for the support and the help on this! finally we’ve fixed this issue 
I’ve also submitted a bug against fedora so they can look into bringing this change/fix back to fedora users.
https://bugzilla.redhat.com/show_bug.cgi?id=2250757
The bug is fixed for KDE 5.27.10 as well as Plasma 6. So once it is rolled out Fedora 39 will also have the bug fix. 
