Getting lost on the 0.1% edge cases or improvements is why I never finish side projects, either.

I don't always manage to adhere to my own advise here. But talking to "customers" really solves this.

Half these customers can't be bothered by the edge cases that I've been poring over for nights. The other half puts forward edge cases that I've never been aware of. Some of which are critical to their work-flow. Many are implemented in mere minutes. "Wow. That saves us 30 minutes typing over prices, every day!".

As an engineer I love to find solutions. But as an entrepeneur I really must understand the problem and scope. that 0.1% edge cases is hardly ever part of the success.

Thanks for posting this, honestly the 0.1% scare me sometimes on technical project. I think you're right, just gotta talk to my customers directly if they even care about it.

I don't think getting the position of the sun is an edge case, it's a fundamental capability for the product to work at all

I believe they meant edge cases when dealing with sun position calculations or maybe other things, not that the sun position is an edge case.

You could probably make a lookup table that works "well enough" in like a few hours.

You could probably make it in a few minutes - the direction of the sun is, to a first approximation, 15 degrees times the number of hours it is after midnight. This leads to a trick for using an analog watch as a compass:

https://www.citizenwatch-global.com/support/exterior/directi...

https://www.watchaffinity.co.uk/blog/how-to-use-your-watch-a...

This is more prone to errors closer to the equator and in the summer (https://possiblywrong.wordpress.com/2012/01/25/using-a-watch...) but should be good enough for picking a side of the bus.

(This is all in the northern hemisphere; in the southern hemisphere the sun goes the other way, so change the sign on everything.)

The equation of time gets in there too if I recall correctly - https://en.wikipedia.org/wiki/Equation_of_time

> The equation of time describes the discrepancy between two kinds of solar time. The word equation is used in the medieval sense of "reconciliation of a difference". The two times that differ are the apparent solar time, which directly tracks the diurnal motion of the Sun, and mean solar time, which tracks a theoretical mean Sun with uniform motion along the celestial equator. Apparent solar time can be obtained by measurement of the current position (hour angle) of the Sun, as indicated (with limited accuracy) by a sundial. Mean solar time, for the same place, would be the time indicated by a steady clock set so that over the year its differences from apparent solar time would have a mean of zero.

And this gets into a neat part of the Clock of the Long Now and a cam needed to keep track of that over 10,000 years. https://longnow.org/ideas/the-equation-of-time-cam-keeping-g...

The equation of time would be in there! But the largest that gets is about 16 minutes, corresponding to a 4-degree error in position, and there are much bigger sources of error. But thanks for the link to the Clock of the Long Now!

Writing the level editor for my raycaster is why I never wrote my raycaster

The hard part was obtaining information such as solar azimuth, altitude, declination, hour angle, etc without using external APIs. Spent around 5 days implementing backend.

Way too late now, but to help others this fancy Excel sheet provided by NOAA is awesome! It implements all of these equations in Excel and is pretty easily portable to your programming language of choice. https://gml.noaa.gov/grad/solcalc/calcdetails.html

P.S. Using this has made it clear to me how bad most sunrise/sunset calculators actually are.

> P.S. Using this has made it clear to me how bad most sunrise/sunset calculators actually are.

That may just be a function of how you define "sunrise" and "sunset". It is never as simple as "when the sun hits the horizon", but something about some number of arc minutes from something something.

Dependent on the refractive index, which depends on air density and temperature and humidity too; and we have to integrate over the region between the horizon and the upper atmosphere (diagonally, of course)…

Haha, thanks ,yep. I learned all this when I lived in the Yukon and sunset takes about 2 hours...

To be clear I was complaining that basically everyone calculates “sunrise” and “sunset” differently. If you check half a dozen different “sunset” calculators you will get a surprisingly wide variation in the times they provide. At least where I live the error seems to average 5-10 minutes.

> At least where I live the error seems to average 5-10 minutes

And what I meant was you are not seeing "error", it's just a difference in definition.

Calculating the solar position is also pretty important when simulating power production of photovoltaics plants. So, the Python library pvlib has nice functions for working with this: https://pvlib-python.readthedocs.io/en/stable/reference/sola...

For anyone wanting to do this calculation yourself, this site is really good: https://www.aa.quae.nl/en/reken/zonpositie.html

I've previously used the formulas on this site to calculate the altitude/azimuth of the Sun and all the planets from a given lat/long/time on Earth.

I'm not sure what you mean by external APIs but is there a reason you're not using SunCalc[1] on the client to process the route after it's returned from the routing engine?

[1] https://www.npmjs.com/package/suncalc