Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sunrise / sunset is incorrect for westerly timezones #491

Open
edwardspeyer opened this issue Nov 6, 2024 · 4 comments
Open

Sunrise / sunset is incorrect for westerly timezones #491

edwardspeyer opened this issue Nov 6, 2024 · 4 comments

Comments

@edwardspeyer
Copy link
Contributor

edwardspeyer commented Nov 6, 2024

Sunrise and sunset are calculated by calling sun_rise_set for the UTC date instead of the local date. This means that the next pair of rise/set times may be for tomorrow instead of the upcoming sunset.

Example: The watch is in San Francisco and the local time is 6pm on October 31st. The sun will set in 12 minutes so the sunrise_sunset_face should show the next pair of events as being (1) the time of today's sunset (6:12pm Oct 31st) followed by (2) tomorrows sunrise (7:37am Nov 1st).

However, the date used for calculating the next rise/set times is based on the UTC time. The UTC time in the example is 7 hours ahead and already on November 1st. The face incorrectly shows the next pair of events as (1) an upcoming sunrise (7:37am Nov 1st) followed by (2) the next sunset (6:12pm Nov 1st).

@edwardspeyer
Copy link
Contributor Author

edwardspeyer commented Nov 6, 2024

I think the fix for this is as simple as follows? I've tested this locally but I haven't really dug deep into seeing if this breaks any other logic.

--- a/movement/watch_faces/complication/sunrise_sunset_face.c
+++ b/movement/watch_faces/complication/sunrise_sunset_face.c
@@ -64,7 +64,7 @@ static void _sunrise_sunset_face_update(movement_settings_t *settings, sunrise_s
     watch_date_time date_time = watch_rtc_get_date_time(); // the current local date / time
     watch_date_time utc_now = watch_utility_date_time_convert_zone(date_time, movement_timezone_offsets[settings->bit.time_zone] * 60, 0); // the current date / time in UTC
     watch_date_time scratch_time; // scratchpad, contains different values at different times
-    scratch_time.reg = utc_now.reg;
+    scratch_time.reg = date_time.reg;
 
     // Weird quirky unsigned things were happening when I tried to cast these directly to doubles below.
     // it looks redundant, but extracting them to local int16's seemed to fix it.

@vagrantc
Copy link

Had the same issue, and your patch worked for me!

@edwardspeyer
Copy link
Contributor Author

edwardspeyer commented Dec 12, 2024

@joeycastillo sorry to not raise this as a pull request; would you consider the above patch?

@vagrantc
Copy link

Might be easier to just submit a pull request than waiting for a response. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants