Use case for "large-dates" feature flag

[jhpratt]

This discussion is for collecting the various use cases of having dates outside of the range -9999-01-01 to +9999-12-31. In time 0.3, support for these values is placed behind the "large-dates" flag, which allows some optimizations for what I believe to be the most common use case.

As indicated in the crate's documentation, this flag may be removed in a future release if there is insufficient demand. Leave your use case below, and use the 👍 reaction if you share this use case. Please do not 👍 a use case that you do not actually need this feature for. Off-topic comments will likely be outright deleted.

[poliorcetics]

We need the feature to safely interact with Windows APIs: FILETIME and SYSTEMTIME can both go way further than +9999-12-31 (around 30827 in fact) so this feature is needed when converting times we got from the Windows API.

[jhpratt]

I'd have to check to be certain, but I believe it involved calculating the Julian day number (either from or to, I forget). That seems inconsequential, but it's actually the underlying manner in which all arithmetic is done with Date objects. That's why I said I think I can branch when the value is in the requisite range for the optimization.

[poliorcetics]

If you think this can be done without impacting everyone else by 15%, sure, let's do it

[jhpratt]

At some point I can run the relevant benchmarks when it's behind an if statement. "At some point" is probably a couple weeks away at least, as I'm writing an RFC, need to review PRs for this repo, and want to do some other unrelated things.

[poliorcetics]

This is not urgent, don't worry about it, I just wanted to chime in to avoid the large dates feature disappearing without replacement. If you have guidance instructions somewhere I can have a look to see if I can work on it, but don't do it if writing them would take too long !

Good luck on the RFC, I should really publish mine someday too

[jhpratt]

It's a breaking change as I mentioned earlier, so it definitely isn't urgent. You're (obviously) the first one to even mention having a use case.

[ChristianBeilschmidt]

We do geoprocessing and usually process data that is collected in recent centuries and now. But there are scenarios, e.g. in landscape modeling, where we look at historic dates way beyond -1k. These are quite inaccurate, but at least with large-dates we can use this library for that and don't need to specially treat this data.

We are currently switching from chrono to time and chrono had wider min and max values. So we are thinking about activating this feature and it would be sad to see it gone.

[ColinFinck]

Thanks for having this discussion before making breaking changes!

Just like @poliorcetics, I'm targeting the Windows world, which internally stores time in an unsigned 64-bit integer that counts the number of 100-nanosecond intervals since January 1st, 1601. My ntfs crate implements the internals of the NTFS filesystem, which also include this time format.

To interoperate with other parts of the Rust ecosystem, I've just implemented converters from and to OffsetDateTime of the time crate. Particularly, a conversion from my NtfsTime to OffsetDateTime is infallible, because OffsetDateTime's nanosecond-precision i128 is a superset of NtfsTime's 100-nanosecond-precision u64.
However, this also requires full support in time for years up to the maximum 60056 supported by NtfsTime. The crate must not impose arbitrary limitations on the value range of the internal i128.
In fact, I'm testing my converters with year 60056 dates to verify their correctness: https://github.com/ColinFinck/ntfs/blob/d54266330757ad2da3da38cd17ff1445a9cee4ae/src/time.rs#L111-L115

[jhpratt]

Thanks. I should actually update the documentation to reflect the fact that the behavior isn't going away in 0.4. There will be a slight change in behavior, but that should make it simpler for everybody.