This patch fixes the case where a negative millisecond offset is passed
to Timezone::timestamp_millis and timestamp_millis_opt and adds a test
case for it. Without this patch, calling timestamp_offset with a
negative value will panic with an overflow like this:
```
---- tests::test_parse_samples stdout ----
thread 'tests::test_parse_samples' panicked at 'attempt to multiply with
overflow',
/home/c/.cargo/registry/src/github.com-1ecc6299db9ec823/chrono-0.4.6/src/offset/mod.rs:349:34
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a
verbose backtrace.
stack backtrace:
0: std::sys::unix::backtrace::tracing:👿:unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at libstd/sys_common/backtrace.rs:71
at libstd/sys_common/backtrace.rs:59
2: std::panicking::default_hook::{{closure}}
at libstd/panicking.rs:211
3: std::panicking::default_hook
at libstd/panicking.rs:221
4: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:477
5: std::panicking::continue_panic_fmt
at libstd/panicking.rs:391
6: rust_begin_unwind
at libstd/panicking.rs:326
7: core::panicking::panic_fmt
at libcore/panicking.rs:77
8: core::panicking::panic
at libcore/panicking.rs:52
9: chrono::offset::TimeZone::timestamp_millis_opt
at
/home/c/.cargo/registry/src/github.com-1ecc6299db9ec823/chrono-0.4.6/src/offset/mod.rs:349
10: chrono::offset::TimeZone::timestamp_millis
at
/home/c/.cargo/registry/src/github.com-1ecc6299db9ec823/chrono-0.4.6/src/offset/mod.rs:327
```
Documentation added to both `impl`s and functions so that they are
visible to both users perusing the online documentation and in
autocomplete/intellisense engines.
And fail CI in the future if `make readme` isn't run when it is needed.
CC conversation in #185, where the README didn't get updated for a year after
lib.rs was improved.
It is the backcompat scheme that we have. In the 5.x timeline we will add the
more-standard and significantly-more-pleasant-to-expand `#[doc(hidden)]
__DoNotMatchAgainstMe` trick.
Unfortunately due to rust-lang/rust#39935 placing the annotation on the `impl`s
of `Encodable`/`Decodable` for the various items have no effect whatsoever, so
we need to place it on some type that chrono actually uses internally. The only
*type* that I can find that only exists for rustc-serialize only is the
`TsSeconds` struct.
So, marking TsSeconds deprecated causes Chrono's internal uses of `TsSeconds`
to emit deprecation warnings, both in our builds and for packages that specify
Chrono as a dependency with the `rustc-serialize` feature active. This means
that the current commit will cause a `warning: use of deprecated item:
RustcSerialize will be removed before chrono 1.0, use Serde instead` to appear
in `cargo build` output.
Unfortunately I don't think that it's possible for downstream crates to disable
the warning the warning in any way other than actually switching to Serde or
using an older chrono. That's the reason for all the `#[allow(deprecated)]`
through the code, it means that the warning appears almost exactly once,
instead of dozens of times.
Rather than the `num` meta-crate, use `num-integer` and `num-traits`
without default features to make them `#[no_std]`. `num-iter` is
just a dev-dependency now for a few test cases.
The only public change is the `impl FromPrimitive for Weekday`, but this
is still the same exact trait that `num` re-exports, so this is not a
breaking change.
Rust is going to change its Markdown rendering engine from hoedown to
pulldown-cmark. In pulldown, a table row starting with just whitespaces
will cause that whole cell disappeared. This causes rendering difference
between the two engines.
To fix this, we add leading and trailing `|` to the rows so that empty
cells are correctly rendered.
Was using static but that's only supported as of rustc 1.17 (rust
these older versions. Also continue using the copious explicit 'static
lifetimes for the same compatibility, despite the clippy lint.
These additions allow convenient control of RFC 3339 formatted output:
* Number of subsecond digits to display
* Whether to use the 'Z' variant, instead of "+00:00" for TZ offset
0, UTC.
...while remaining faithful to the RFC 3339. The implementation uses
the existing formatting Item mechanism.
github: cc: #157#178
Current clippy is probably correct, but its a breaking change that
isn't appropriate now. Add allow's to get the build working again.
Also these Date(Time)::signed_duration_since cases appear to match
there `Naive` counterparts, where clippy isn't complaining. If its
fixed in the future, should probably be changed across the board, not
just here.
Now (assuming clippy is right) all (~100) uses of ` as ` in the code are
actually doing casts that could potentially silently lose data. Woooo?
At least this means that new `as`s can be extra-scrutinized, and we should
probably be adding debug_assert!s for the casts in real code.
The implementation is identical to how #[derive] would do it, and we use the
implementation to add some documentation warning people not to use items with
nanosecond-level precision in hash maps unless they're sure that's what they
want.
kennytm
Brandon W Maister
Mahmoud Al-Qudsi
jean-airoldie
Andrei Nesterov
Casey Marshall
Vasili Revelas
Pascal Bach
storyfeet
novacrazy
寧靜
Evan Schwartz
Thomas Bytheway
Toby Dimmick
Jethro Beekman
Philipp Hansch
David Kellum
Josh Stone
Jordan Petridis
Xidorn Quan
Kosta Welke
Jonas Bushart