Consider adding support for BCE years

[Badg]

Hello hello!

So this is maybe a bit of an unusual and/or half-baked request, but: is there a technical reason not to support negative numbers for years? I for one would find it (occasionally) useful to be able to do math, particularly with Instants, that are BCE, ie, have negative years.

---

Note: I realize this doesn't make a ton of sense for most applications, but I'm designing a data warehouse system with historical data being explicitly in-scope, and we use whenever for all of our time manipulations. Particularly when it comes to some scientific applications (for example, prehistoric climate data), it is entirely imaginable that some of our users might want to reference dates in the deep past. Our current plan is to have our time zeropoint be the approximate beginning of the holocene (ie, 10k BCE, as popularized by Kurzgesagt). Though we have a lot of wiggle room in our internal time bitpacking (literal millions of years), so... don't nail me to the wall on that or anything. Anyways, point being, it'd be nice if we could simply calculate a direct offset from the 10k BCE number, instead of hard-coding an offset until then based on number of seconds.

[ariebovenberg]

Hi @Badg, thanks for opening this issue. Happy to hear whenever is of use to you!

There are a few reasons for the current boundary of 1..9999:

• It's the same as datetime. This ensures good interop with the standard library. Also, it allows the pure-Python version of whenever to reuse bits of datetime relating to the calendar.
• Common formats RFC3339 and RFC3333 don't support negative or >9999 years. ISO8601 doesn't either "without mutual agreement". If whenever supported negative years, these formatting/parsing methods would fail
• Larger bounds would increase the size of every type, and degrade performance in the general case

---

I'm not completely opposed to it, but I'm skeptical that widening to -9999 would settle this. Anybody who'd need BCE years (geology, climate, astronomy) would probably need years beyond ±10.000, and should use a specialized library. Each boundary is essentially arbitrary. The current one buys datetime and RFC2822/3339 compatibility.

If widening the bounds, I'd consider going for -9999..9999 like Jiff does.

I'll keep this issue open for discussion

edit: formatting