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.
Starting from this version the `CHANGELOG.md` file is the canonical
source for the list of significant changes. See the file for details.
Fixes#146.
Fixes#159.
Due to the obvious lack of time zone information in `SystemTime`,
`SystemTime` can only be converted to `DateTime<Utc>` (in UTC) or
`DateTime<Local>` (in the local time zone), while any `DateTime<Tz>`
can be converted to `SystemTime`.
This removes `Datelike::isoweekdate` in favor of `Datelike::iso_week`.
The original `isoweekdate` was not named in accordance with the style
guide and also used to return the day of the week which is already
provided by `Datelike::weekday`. The new design should be more
reasonable.
Note that we initially do not implement any public constructor for
`IsoWeek`. That is, the only legitimate way to get a new `IsoWeek` is
from `Datelike::iso_week`. This sidesteps the issue of boundary values
(for example the year number in the maximal date will overflow in
the week date) while giving the same power as the original API.
Partially accounts for #139. We may add additional week types
as necessary---this is the beginning.
Linkchecker recognizes the distinction between internal and external
links (which are not checked by default), and considers URLs which
does not have the starting URL base as a prefix internal...
This commit has been verified against a proper set of options to
Linkchecker, but there are several false positives (for our purposes)
which would make the automated checking not as effective. </rant>
There used to be multiple modules like `chrono::datetime` which only
provide a single type `DateTime`. In retrospect, this module structure
never reflected how people use those types; with the release of 0.3.0
`chrono::prelude` is a preferred way to glob-import types, and due to
reexports `chrono::DateTime` and likes are also common enough.
Therefore this commit removes those implementation modules and
flattens the module structure. Specifically:
Before After
---------------------------------- ----------------------------
chrono:📅:Date chrono::Date
chrono:📅:MIN chrono::MIN_DATE
chrono:📅:MAX chrono::MAX_DATE
chrono::datetime::DateTime chrono::DateTime
chrono::datetime::TsSeconds chrono::TsSeconds
chrono::datetime::serde::* chrono::serde::*
chrono::naive::time::NaiveTime chrono::naive::NaiveTime
chrono::naive:📅:NaiveDate chrono::naive::NaiveDate
chrono::naive:📅:MIN chrono::naive::MIN_DATE
chrono::naive:📅:MAX chrono::naive::MAX_DATE
chrono::naive::datetime::NaiveDateTime
chrono::naive::NaiveDateTime
chrono::naive::datetime::TsSeconds chrono::naive::TsSeconds
chrono::naive::datetime::serde::* chrono::naive::serde::*
chrono::offset::utc::UTC chrono::offset::UTC
chrono::offset::fixed::FixedOffset chrono::offset::FixedOffset
chrono::offset::local::Local chrono::offset::Local
chrono::format::parsed::Parsed chrono::format::Parsed
All internal documentation links have been updated (phew!) and
verified with LinkChecker [1]. Probably we can automate this check
in the future.
[1] https://wummel.github.io/linkchecker/Closes#161. Compared to the original proposal, `chrono::naive` is
retained as we had `TsSeconds` types duplicated for `NaiveDateTime`
and `DateTime` (legitimately).
I think it's a terrible API, but AFAIK rustc-serialize doesn't support anything
like serde's `with` attribute.
I think it would be better to just not include this API at all and require that
people who want to use this move to serde, which is the recommended rust
encoding/decoding library.
This introduces a newtype around DateTime and NaiveDateTime that deserlization
is implemented for.
There are two advantages to this over the previous implementation:
* It is expandable to other timestamp representations (e.g. millisecond and
microsecond timestamps)
* It works with RustcSerialize::Decodable. AFAICT Decodable will error if you
try to call more than one of the `read_*` functions in the same `decode`
invocation. This is slightly annoying compared to serde which just calls the
correct `visit_*` function for whatever type the deserializer encounters.
On the whole I think that I prefer this to the previous implementation of
deserializing timestamps (even though I don't care about RustcSerialize in the
post-1.15 world) because it is much more explicit.
On the other hand, this feels like it's introducing a lot of types, and
possibly making downstream crates introduce a variety of different structs for
ser/de and translating into different struct types.
Timestamps are defined in terms of UTC, so what this does is, if we encounter
an integer instead of a str, create a FixedOffset timestamp with an offset of
zero and create the timestamp from that.
- Serde 1.0 is now supported. (#142)
Technically this is a breaking change, but the minor version was not
effective in avoiding dependency breakages anyway (because Cargo
will silently compile two versions of crates). Provided that this is
likely the last breakage from Serde, we tolerate
this more-than-last-minute change in this version.
- `Weekday` now implements `FromStr`, `Serialize` and `Deserialize`.
(#113)
- Fixed a bug that the leap second can be mapped wrongly
in the local tz with some conditions. (#130)
- Some changes to the tests to avoid previously known issues.
Note that the actually published version is very slightly different
from the repository because no published version of bincode supports
Serde 1.0 right now.
Evan Schwartz
Brandon W Maister
Thomas Bytheway
Toby Dimmick
Jethro Beekman
Philipp Hansch
David Kellum
Josh Stone
kennytm
Jordan Petridis
Xidorn Quan
Kosta Welke
Jonas Bushart
Kang Seonghoon
Ben Boeckel
Ashley Mannix