The big ones here are:
1. Using Neri-Schneider to convert to-and-from Unix epoch days.
2. Add a bit set to `Span` to make it cheap to determine which units
are non-zero. We then use this bit set to enable fast paths in
routines that do arithmetic with `Span`.
There's a host of other junk here too. For example, `Timestamp::series`
now converts its `Span` to a `SignedDuration` and uses that to do
arithmetic instead of `Span`. And adding a `SignedDuration` to a
`Timestamp` is now faster because we avoid doing redundant checks by
skipping `Timestamp`'s constructor.
... and a lot more of that in a similar vein.
This overall results in better performance than both `chrono` and `time`
in *most* cases.
Fixes#235, Fixes#255
Since jiff-icu depends on jiff, making jiff depend on jiff-icu for dev
causes a loop that leads to extra compilations when running tests for
jiff. This is annoying, because it means it's harder to run tests and
show doc examples that use jiff-icu. Bah. But there was only one, so
just mark it as `text` for now to ignore it completely.
Basically, anywhere we linked to the `icu` crate, we now also include a
mention of `jiff-icu` to facilitate conversions. And we update our
comparison example to include use of this crate.
This makes the `Span` APIs more consistent with the rest of Jiff in that
days are never silently assumed to be 24 hours. Instead, callers are
forced to either provide a relative date or a special
`SpanRelativeTo::days_are_24_hours()` marker to opt into invariant
24-hour days.
This is meant to make the API more uniform and reduce the possibility of
bugs. In particular, in #48, it was brought up that it is very easy to
assume that Jiff APIs will never let you silently assume that days are
always 24 hours. This is actually quite easy to do if you're just
dealing with `Span` APIs.
Fixes#48
Previously, it was an API bug for this routine to be infallible since we
specifically disallow adding calendar spans on `Timestamp`. To paper
over this, we made the API panic in such cases. But now we properly
return an error.
It is lamentable that an API like this is fallible. And the generics
means that even adding a `SignedDuration`, which ought to be infallible,
callers still need to deal with the possible error path.
Fixes#36
Pretty much what it says on the tin. The idea here is that two different
`Span` values in memory, which compare not equal, might still be the
same duration. Obviously I knew this when I added the trait impl
originally, and realized it could be a footgun, but I thought its
convenience outweighed the footgun. However, I think #32 pretty
convincingly argues that it's the wrong default.
If this ends up being the wrong decision, we can always add the trait
impl back. In particular, I am worried about this making `Span` a very
annoying-to-use type. Not implementing basic equality is just super
annoying because it's common to want it in tests and other various
things where the footgun isn't really relevant. But at least this way,
we can fix the mistake in the future.
Ref #32
This somewhat revives #22, but makes it possible to restore the previous
behavior by enabling `jiff::fmt::temporal::SpanPrinter::lowercase`.
The main motivation here is also detailed in #22, and it came up again
in #188. I was previously reluctant to do this because I find
`P1Y2M3DT4H5M6S` hideously difficult to read and `P1y2m3dT4h5m6s`
somewhat less difficult to read. But now that `jiff::fmt::friendly` is a
thing and users have easy access to a more readable duration display
format, I feel less bad about this. It's still a shame that it's the
default via `span.to_string()`, but I tried to sprinkle a few
`format!("{span:#}")` in places to nudge users toward the friendly
format.
It's a shame more systems don't accept lowercase unit designator labels,
but since Jiff uses the ISO 8601 by default specifically for its
interoperability, it makes sense to be as interoperable as we can by
default.
Fixes#188
The saturating methods *should* return an error. But I goofed on the
API. So at this point, our two choices are: leave it as-is, which
produces completely incorrect results when there are non-zero units of
days or greater, or panic when it occurs. I think a panic is better.
In Jiff 0.2, these APIs will be made fallible. And hopefully by then
we'll have truly infallible APIs that accept an "absolute" duration.
Partially addresses #36
Basically, using `DateTime<Local>` is a touch weird here. But I've left
that in because I think it's a legitimate oddity of Chrono's API. In
this commit, we add an example that utilizes `chrono-tz` and brings up
the fact that it doesn't have Serde support.
This is in response to feedback I got on programming.dev from BB_C[1].
[1]: https://programming.dev/comment/11228934
