Basically, if callers opt into days being invariant---and thus no
relative date is required to resolve its length---then weeks are also
treated as invariant.
Temporal doesn't do this. As I understand it, I think the reasoning is
that they might some day support calendars that don't use 7 day weeks.
However, I think it's still pretty unlikely for Jiff to support
non-Gregorian calendars (other than things like the ISO 8601 week date
calendar). And moreover, I believe the only calendars to use weeks that
aren't 7 days are ancient calendars. I believe all actively used
calendars use 7 day weeks. So for this assumption to be wrong, Jiff
would not only need to support non-Gregorian calendars but _ancient_
non-Gregorian calendars. I think that's probably never going to happen
and is best left to specialty crates.
Because of that, I think it's say to support invariant weeks *when* the
caller opts into invariant days.
Closes#136
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
This does make _some_ use cases a bit more annoying, but I think it
overall makes the API more consistent. Essentially, unless
`SpanRelativeTo::days_are_24_hours` are provided, then Jiff will always
consider days to be a variable unit like weeks, months and years.
Previously, this would only happen _some_ of the time.
For now, when that assumption is silently made, Jiff will emit a
deprecation warning. This will turn into a hard error in `jiff 0.2`.
Ref #48
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
It turned out that our feature config testing was somewhat FUBAR.
Namely, we were accidentally and unconditionally always enabling the
`std` feature (among other default features) when running tests. This
was a result of this *dev* dependency:
jiff = { path = "./", features = ["serde"] }
I fixed this by disabling default features to require explicit opt-in:
jiff = { path = "./", default-features = false, features = ["serde"] }
Because this setup languished for a while, there was some accumulated
cruft that warranted some fixing. Mostly this was about gating more code
that isn't used in certain feature configs. I loathe to do this since I
find it abstraction busting, but I'm not sure if there is a great
alternative.
This was bad timing. The lang team just stabilized (in nightly) a new
deny-by-default lint, named `ambiguous_negative_literals`, which
triggers an error for things like `-1.hour()`. While such things can be
confusingly ambiguous in some cases, in Jiff, `-1.hour()`, `(-1).hour()`
and `-(1.hour())` are all, very intentionally, precisely equivalent.
For now we just `allow` the lint. If the lint stays, we'll likely want
to recommend allowing it in the Jiff docs.
See: https://github.com/rust-lang/rust/pull/121364
