Lower bound of time needs to be lower

[homedry]

What's the problem?
When I set the year smaller than -3000, the number is fixed into -3000.

Can ivoyager be set the lower bound of time like, -10000?

My usage requires this.

I'd appreciate your consideration.

Thank you

[charliewhitfield]

The Keplerian orbital elements and adjustments in planets.tsv are from this page (Table 2a, 2b), so are only accurate from 3000 BC - 3000 AC. That's the reason for the limit. It's an easy "fix" in the code. Some considerations:

For the on-line Planetarium, here are the options I can think of:

1. Keep the current limit, since we are striving for astronomical accuracy.
2. Allow setting to anything, with a warning that the sim isn't accurate outside of the range.
3. Use a different data source that expands the validity window. However, this would lower accuracy in the 3000 BC - 3000 AC range.
4. Provide a setting in the Options panel to select different source data optimized for different ranges. (The link above provides another data set more accurate in the narrower 1800 AD - 2050 AD range.) This is obviously the most work...

For developers using the ivoyager_core plugin, the limit is kind of trivial. The existing limit is set in the year SpinBox here. As a code improvement, that should really be elevated to IVCoreSettings so it is more accessible to external project.[edit: limit expanded to +- 1e12!]

If you are developing your own project, you can use a different data set optimized for the range you need. You can create a "mod" table that modifies orbital elements in the existing table.

[charliewhitfield]

OK, I went with option 2 above. The setter widget is unlocked. Well, to be honest, it's now limited to +- 1e12 years.

I added this text to the widget with working links (which also addresses another issue):

"The simulation uses Keplerian elements and rates for planets valid from 3000 BC to 3000 AD. Planet positions will not be accurate outside of this range. There is also an open issue to fix orbits of the Hilda asteroids, which visibly lose their 3:2 resonance with Jupiter over several centuries from J2000."

Developers can use whatever planetary orbit data they want, so the 3000 BC - 3000 AC choice in base tables isn't really an issue.

Option 4 above is intriguing. The mechanisms to do it are all present in our plugin code. But it would be significant work. Someone can open a proposal if they don't want this forgotten.

The fix is in the master branch (changlog) and will be in v0.0.18 release, so I'm closing the issue as completed...