Night Light auto schedule uses timezone instead of geographic coordinates — incorrect sunrise/sunset for locations far from timezone center

[sporteka2]

Summary

Night Light "Auto" schedule calculates sunrise and sunset times based on the system timezone (e.g., Europe/Moscow), not actual geographic coordinates. This gives incorrect results for users living far from the timezone reference point.

Example

Location	Timezone	Sunrise (Jul 11)	Sunset (Jul 11)
Moscow (55.8°N, 37.6°E)	Europe/Moscow	~03:50	~21:10
Makhachkala (42.9°N, 47.5°E)	Europe/Moscow	~04:20	~19:30

Both use Europe/Moscow, but sunset differs by 1h40min. A user in Makhachkala will have Night Light turn on 1h40min too late and turn off 30min too early.

Expected behavior

Auto mode should either:

1. Use the coordinates from night-light-last-coordinates gsetting (when manually set by user via gsettings or gammastep/redshift config), falling back to timezone-based estimation if no coordinates are set
2. Or allow selecting a city/coordinates in the Night Light settings GUI
3. Or at minimum document that Auto mode is timezone-based and recommend Manual schedule for accurate times

The night-light-last-coordinates key exists in org.cinnamon.settings-daemon.plugins.color schema but is only used as a cache for GeoIP data — unused when the user sets it manually or when GeoIP is unavailable.

Current workaround

Use "Manual" schedule with custom times, or set coordinates via:

gsettings set org.cinnamon.settings-daemon.plugins.color night-light-last-coordinates "(42.9, 47.5)"

(these coordinates are currently ignored by the auto schedule calculation)

System

• Cinnamon 6.6.7
• Linux Mint 22.3 Zena
• X11

[sporteka2]

Another problem with the Manual schedule workaround: sunrise and sunset shift ~30-60 seconds per day, so to keep Night Light perfectly in sync you would need to update the manual times every single day. This makes Manual schedule impractical for anyone who wants accurate sunrise/sunset tracking.

The Auto mode should use geographic coordinates (from night-light-last-coordinates or a user-set location) rather than just timezone, so the schedule stays accurate year-round without daily manual adjustments.

[mtwebster]

If I recall, relying on the timezone was a deliberate choice when we implemented this, as existing open geo-location libraries were (still are?) unreliable or broken.

I think we'd be open to making the location key usable (I think it merely updates to whatever the timezone origin is, currently), but not really interested in anything like geo-ip location.

[leigh123linux]

I think we'd be open to making the location key usable (I think it merely updates to whatever the timezone origin is, currently), but not really interested in anything like geo-ip location.

It's only 11 lines needed for ip geo to provide lat,lon

import json
import urllib.request

def get_location():
    with urllib.request.urlopen("https://ipinfo.io/json", timeout=5) as resp:
        data = json.loads(resp.read().decode())
    lat, lon = data["loc"].split(",")
    return float(lat), float(lon)

lat, lon = get_location()
print(lat, lon)

$ python geo.py 
50.799 -1.0913

[mtwebster]

Typically I don't think these services would appreciate the flood of traffic our including it in Cinnamon would result in. We'd be better off adding a forwarder on one of our own servers.