Error in sunrise / sunset calculations

[cceckman]

I'm in the US Eastern time zone, same as Washington, DC.

This gist contains:

1. A program for generating the rise/set times for Washington, DC, using satkit::lpephem::sun::riseset
2. The output of that program

The output shows the day lengthening up to the winter equinox, then abruptly shrinking:

2024-12-18 04:47:54 -05:00 // 2024-12-18 19:21:53 -05:00
2024-12-19 04:48:20 -05:00 // 2024-12-19 19:22:28 -05:00
2024-12-20 04:48:49 -05:00 // 2024-12-20 19:23:00 -05:00
2024-12-21 07:23:31 -05:00 // 2024-12-21 16:49:18 -05:00
2024-12-22 07:23:59 -05:00 // 2024-12-22 16:49:50 -05:00
2024-12-23 07:24:26 -05:00 // 2024-12-23 16:50:24 -05:00

Neither of these things match my experience of how sunrise and sunset actually behave. :)

First, for coordinates 39.0, -77.0, the day length should decrease up to the equinox (December 20). Second, for any coordinates, rise and set times should be approximately the same day-to-day (unless there are discontinuities in civil time).

Is there some sort of sign error here that is causing the northern-hemisphere day to lengthen as the winter equinox approaches?

[ssmichael1]

Something is definitely wrong with the calculation, as there is a large discontinuity at the equinox. I think it is a quadrant issue with an arctan; this function is not well vetted. I will look.

I had checked it against, for example, : https://www.timeanddate.com/sun/usa/washington-dc

but only for a few locations and days.

[ssmichael1]

Indeed the issue is a quadrant with arctan. I needed to do a quadrant-aware arctan when computing position of sun in the equatorial plane (rotating from ecliptic).

I did a cursory check of calculations using your code against: https://www.timeanddate.com/sun/usa/washington-dc

Results look accurate for spot checks that span 4 seasons and daylight savings.

A new version is published to crates.io

[cceckman]

Agreed, at some spot checks the 0.3.14 version looks like it's doing the right thing. Thanks for the fix!