What range of years do you need support for in the time crate?

Currently, the time crate has support for years ±100,000 inclusive (negative years are astronomical year numbering). I am currently in the process of redesigning and optimizing a number of things for a 0.3 release. Some things could be simplified or further optimized were the range of valid years restricted.

On the main branch, the range is currently widened to ±999,999 inclusive, but I am obviously looking to narrow this. +1 to +9999 is the absolute minimum range I'm even considering, but ±9999 is what I'm eyeing. What range of years would you like to see support for?

Wasn't the time crate absorbed by the chrono crate?

1 Like

To my knowledge, chrono is (slowly) pulling in the chunks of time 0.1 that they rely on. I began development of time 0.2 in September 2019; it has been under active development for over a year. Time 0.2 and chrono have no relation whatsoever.

If it were me, I would:

  1. Investigate the core time libraries used in other ecosystems (C++, Java, Go, JavaScript, Python at minimum) and determine their supported time range.
  2. Scrutinize the issue tracker to see if there are any popular open bugs or feature requests to change the time range.

IMO, that alone will give you a much more solid footing than any kind of impromptu poll on this forum will.

18 Likes

I'll definitely do that. Still worth asking here imo

My personal take is that exact time doesn't matter for years far outside our civilization's time scale. Astronomy will need scales in millions of years, and probably also keep track of relativistic effects, so it won't use a vanilla time crate.

1 Like

IIRC that last time I had to make a choice like that I made it assert for anything that ended up after 9999-12-31 and nobody has ever complained. (This was in C++.)

TBH, I don't think I'll ever need any dates outside 1600-03-01 to 2400-02-28. (Picked to be almost two full gregorian cycles, avoiding the unusual leap days on the ends.)

Honestly, I think that anyone needing more than ±200 years probably needs a specialist time crate, not a normal one. (Even inside that it might be warranted -- if you want to have the October revolution in October instead of the modern November...)

2 Likes

The Gregorian system will be off by more than a day by the time Y10K rolls around, as I understand it. (I don't have an opinion on what the crate should do, but perhaps the factoid is useful.)

I've been aware of that fact since long before I created the crate :laughing:

My current thought is to limit the range to ±9999, which should be more than enough for most use cases. This will allow me to further optimize some frequently-used functionality. Years with at least five digits (likely up to ±999,999) will have support behind an optional feature flag; enabling that will lose some optimizations.

Won't putting it behind a feature flag mean that if any one of my dependencies use that feature then I'm forced to lose the optimizations?

Maybe that's less of an issue for a rarely used specialised feature such as this but it feels like a gotcha.

Yes. If an upstream crate relies on the feature, though, disabling the flag (thus enabling further optimization) would break their code.

So maybe a feature flag isn't ideal for this use? One outcome is worse than the other but they're both not good. If the optimization is worth writing then someone is going to rely on it and be surprised when they get a mysterious slow down. Even if they happen to be aware of this issue they might face having to check their whole dependency graph to find the offending crate that's enabling the feature.

I'm talking a 15-20% improvement in performance, not 10x. Regardless, if a library enables the flag, they're presumably doing it for a reason.

How on earth does limiting years to 4 digits give optimizations?

First off all, please watch your tone.

It's not the four digits per se that lead to the optimizations; that restriction will be in place to limit ambiguities when parsing the textual representation of dates. Limiting the size of the year component let me avoid using an i64 instead of an i32, as the former caused an overflow during some arithmetic. This alone led to noticeable performance gains: my measurements showed a 40% improvement in one method and a 15% improvement in all arithmetic.

You might also want to have a look at what file systems support. It's usually nice if it can take any dates that come from the OS as-is, even weird values. E.g. ext4 apparently supports:

• Date range: December 14, 1901 - April 25, 2514
1 Like