Add seconds to solstice/equinox times

[gdt]

I was talking with others outside at the time of the winter solstice, and noticed that the time is given to minutes. I told them (mostly proprietary software users) that because of the wonder of open source, I'd file a bug and next year I'd have seconds :-)

But seriously, my impression is that the solstice is very well defined physically, and there is nothing about location. elevation, topography, weather that affects it, and thus it should be possible to calculate to the second. So if that is indeed sensible, it would be nice to add.

[forrestguice]

that because of the wonder of open source, I'd file a bug and next year I'd have seconds

lol. This seems about right. Its a quick change, so probably a lot sooner than a year.

If you need this value now, there is an option, 'show seconds', buried in the UI settings, but its applied to all fields. It defaults off to avoid giving a false sense of accuracy - the algorithms for sunrise/sunset/twilight are typically only accurate to the minute.

We could always report seconds for the solstices/equinoxes though. Especially if that's what most expect, but I'm not really sure. I'm searching around and it seems most sites only publish to the minute. I'm debating it. Anyhow, the change is a one-liner, so even if the decision goes the other way, its pretty easy to personally have seconds anyway. The proprietary stuff definitely can't do that ;)

[gdt]

I think there are two separable issues. One is the usual "don't print more precision than is warranted", and I think you confirmed that seconds for solstice is meaningful, but seconds for sunrise is not. The other is "does the reader care", and I'm the type to want seconds on my watch (synced to WWVB nightly), and on my on-screen clock display. I find it very strange that searching for solstice times on the web doesn't turn up anything with seconds. The second case is harder to pick a default for. But my impression is that this program is aimed a little more towards nerds than normals compared to the population mix.

One point is that the choice of seconds or not somewhat signals accuracy. That argues for showing them for solstices. Another is that it's much easier to ignore seconds if you don't care than to figure out how to turn them on if you do.

So my vote is for enable seconds for solstice/equinox in the popup always, but leave it at minutes in the main screen. I don't think that will bother those that don't care very much, compared to the benefit for those who do. I only care about the seconds for the hour before, and especially during the minute.

I have turned on the setting, which I didn't know about (usually I got through all menus but I've been running this ~forever and maybe forgot or maybe it's "new") so given that I know seconds aren't really valid for sunrise, I'm able to see them for the solstice with no ill effects.

[forrestguice]

enable seconds for solstice/equinox in the popup always

This seems like a reasonable compromise. It'll be in the next patch (v0.13.18).

I think the accuracy is something we should still question though (its really whatever the library reports), but there's no harm showing those values in the right context. I also plan to add the length of the tropical year in v0.14.0, but I've noticed the calculated values differ a few seconds from those reported by timeanddate, which reports seconds for the tropical year, but doesn't seem to report them for the solstices/equinoxes. 🤷

usually I got through all menus but I've been running this ~forever and maybe forgot or maybe it's "new"

That "show seconds" option is an old one, but its been moved around a few times. It was previously in General Settings, a much more prominent location. I think the 'data source' options might be buried in the same way (while restoring 'show seconds' to General).

I think these are advanced options - there isn't really any reason the average user would want to choose one 'source' over another (the default is the best option). The option remains though because its the ultimate control over precision (you can swap out one library for another, write your own, etc), as well as a control on performance. The default is guaranteed to consume the most cycles (or so I've been warned), but it also doesn't seem to be important (always seems 'fast enough'). It's still an option to purposefully choose a quicker (less accurate) algorithm.

btw, I like the suggestion of putting info about this option on the wiki. Adding some in-app help text that links to it, and a blurb about potential extensibility would help clear up any confusion as to its purpose.

[gdt]

Thanks, and all sounds good. It would be nice, if all the calculation backends returned an accuracy (1 sigma?) as well and this were shown, with a nerdy option. I really don't have handle on how that is.

BTW, semi-relevant, length of day is shown to seconds. That seems unjustified, but lenght(yesterday)-length(today) seems likely to be meaningful.