This comes from:
https://www.benjoffe.com/fast-date-64
More specifically, the code is here:
7fcf82b07d/algorithms/benjoffe_fast64.hpp
But the benchmarks don't show an improvement:
```
$ critcmp base x01
group base x01
----- ---- ---
civil_datetime/to_timestamp_static/bundled/jiff 1.00 10.5±0.09ns ? ?/sec 1.03 10.9±0.07ns ? ?/sec
civil_datetime/to_timestamp_static/zoneinfo/jiff 1.00 10.4±0.09ns ? ?/sec 1.03 10.8±0.07ns ? ?/sec
timestamp/to_civil_datetime_offset_conversion/jiff 1.00 4.4±0.05ns ? ?/sec 1.03 4.6±0.03ns ? ?/sec
```
I ran the benchmarks like this:
```
cd bench
```
Before the change:
```
cargo bench --'(civil_datetime/to_timestamp_static|timestamp/to_civil_datetime_offset_conversion).*jiff' --save-baseline base
```
And then after the change:
```
cargo bench --'(civil_datetime/to_timestamp_static|timestamp/to_civil_datetime_offset_conversion).*jiff' --save-baseline x01
```
Then I used [`critcmp`] to compare them:
```
critcmp base x01
```
It's very possible I didn't port it correctly. I haven't scrutinized the
codegen. It's also possible that there is an improvement, but that it's
hard to write a benchmark using Jiff APIs to observe it.
(Note that I left out the ARM-specific bits. I'm testing this on x86-64.
I wanted to test there first before digging into the platform specific
optimizations.)
[`critcmp`]: https://github.com/BurntSushi/critcmp
It looks like `icu_time::zone::models::Full` has been deprecated. So we
need some `allow(deprecated)` to squash the warnings. And we implement a
`TryFrom` for `ZonedDateTime<Iso, TimeZoneInfo<AtTime>>` as its
replacement.
Previously, I think this would have lost some information, but it sounds
like icu4x can now figure out the right DST status without being told.
Ref https://github.com/unicode-org/icu4x/pull/6754
Ref https://github.com/unicode-org/icu4x/pull/6755
See the comment in the code for explanation, but basically, this comes
from S 3.3.1 of RFC 9636:
> 3.3.1. All-Year Daylight Saving Time
>
> DST is considered to be in effect all year if its UT offset is less
> than (i.e., west of) that of standard time, and it starts January 1
> at 00:00 and ends December 31 at 24:00 minus the difference between
> standard and daylight saving time, leaving no room for standard time
> in the calendar. [POSIX] implies but does not explicitly state this,
> so it is spelled out here for clarity.
>
> Example: XXX3EDT4,0/0,J365/23
> This represents a time zone that is perpetually 4 hours west of UT
> and is abbreviated "EDT". The "XXX" is ignored.
These odd time zones can occur when compiling TZif files using `zic`
with rearguard semantics. In particular, this applies for times at or
after 2087 in `Africa/Casablanca`. Rearguard semantics are used by
Jiff's `jiff-tzdb` crate, but aren't always otherwise used in standard
`/usr/share/zoneinfo` installations. As a result, this bug's effects
cannot always be consistently observed.
Fixes#386
Previously, it was possible for lenient formatting to still error when
the formatting string contained invalid UTF-8. This commit alleviates
that error condition by writing a replacement character instead. This
required tweaking our UTF-8 decoding routines so that we could implement
the "substitution by maximal subparts" strategy for lossy decoding.
This now means that lenient formatting can only fail when writing to the
underlying writer fails.
In https://github.com/rust-lang/rust/pull/138907, the `doc_auto_cfg`
feature was subsumed by `doc_cfg`. This does overall looks like we're on
a path toward stabilization, which is great.
One problem here though is that a bunch of crates use the `cfg`
`docsrs` to enable `doc_auto_cfg`. So if we enable it, then it causes
those crates to emit hard errors. This is overall very annoying, and
I don't know how to unfuck things. So I changed the `cfg` knob to
`docsrs_jiff` which, doesn't quite provide a guarantee, but gets us
closer to being masters of our own destiny.
See also a similar change made to `regex`:
https://github.com/rust-lang/regex/pull/1305
This can only happen when malformed TZif data is given. Generally
speaking, Jiff treats TZif data as untrusted and promises not to panic
when given malformed data. So this is something that ought to be fixed.
However, it's rare to use untrusted TZif data in practice.
In this specific case, we were assuming that the time zone designation
list was always terminated by NUL.
Fixes#423
The first one here was pretty embarrassing: the parser panicked on the
empty string.
The others were a bit subtler and had to do with incorrect construction
of error messages. Arguably, more tests for the error cases here ought
to be added.
Fixes#407
This basically does what is necessary to get everything compiled and
tests passing.
We'll add on time zone and offset stuff in a subsequent commit.
Note that we now depend on `icu_calendar` and `icu_time` directly, with
the latter being optional (but enabled by default). In particular, one
can do useful things with just conversions to dates with `icu_calendar`.
But I expect most folks will want both.
In practice, we do this because otherwise
`cfg_attr(feature = "perf-inline")` will throw a warning otherwise. And
that happens because we use these annotations in code in Jiff that is
shared (via copying) with `jiff-static`. So instead of just removing the
annotations, we add `perf-inline` as a feature to `jiff-static`.
For `jiff-static`, we disable it by default, since we don't really care
about that level of perf when doing datetime calculations at compile
time.
This apparently got out of date. And it was apparently not being
enforced in CI. And the destination directory used by `jiff-cli` was
outdated. So fix all of that here, including re-generation.
I'm not sure when or how exactly it happened, but in the last weeks,
I've noticed that `rustc` gets effectively stun-locked whenever I make a
change to a source file in Jiff. A quick examination of what the fuck my
computer is doing seems to reveal that it's spending oodles of time
compiling diesel over and over.
I have no idea why this is happening and I don't really care to spend
the time unraveling the mysteries of diesel.
So I took a hammer to the problem. I have effectively shunted all
examples and all "integration" crates out of Jiff's core workspace and
into their own little bloated fiefdoms. To compensate for the fact that
`cargo test --all` no longer tests these things, I've added shell
scripts to run the requisite tests. And those shell scripts are now run
in CI.
I'm now back to a state where I can save a file in Jiff and I get
sub-second `cargo check` response times.
I wasn't sure why `cargo package` wasn't picking up
`crates/jiff-static/shared`. So I switched to a traditional `src`
layout, which shouldn't be necessary. Indeed, that didn't fix things.
Turns out, I had a bunk `include` rule.
But I wanted to switch to the `src` scheme anyway, so leave that.
This makes binary search for TZ lookups substantially faster.
This is yet another brutal refactor. Changing anything in POSIX time
zones or TZif handling is now a monster pain in the ass because all
of that code is shared in a very awkward way with `jiff-static`.
Ref #271
