Something that wasn't part of this PR: the work to support nested
`Option<[ChronoType]>` was merged without being adjusted for the no-std
support
And now there are some unused import warnings because they need to get
configged out.
The Item::Space calls str::trim_left and Item::Numeric also calls
str::trim_left before doing anything else, so there is no need to
have Item::Space before Item::Numeric.
Speeds up parsing:
name remove-cloned ns/iter simplify-from-str ns/iter diff ns/iter diff % speedup
datetime::tests::bench_datetime_from_str 582 448 -134 -23.02% x 1.30
datetime::tests::bench_datetime_parse_from_rfc2822 244 242 -2 -0.82% x 1.01
datetime::tests::bench_datetime_parse_from_rfc3339 239 234 -5 -2.09% x 1.02
The parse::parse and format::format functions accepted Iterator of owned
Items. While it is sometimes convenient to pass in the owned values,
neither of the functions really need to own them, so references would
be enough. The Borrow trait allows us to pass in Iterator over values,
references, boxes, etc.
According to RFC 1105 this is a minor change, because it shouldn't break
any existing code. And chrono is in pre-1.0 version anyway.
This allows us to remove multiple cloned() calls which speeds up parsing
and formating:
name control ns/iter remove-cloned ns/iter diff ns/iter diff % speedup
datetime::tests::bench_datetime_from_str 712 582 -130 -18.26% x 1.22
datetime::tests::bench_datetime_parse_from_rfc2822 252 244 -8 -3.17% x 1.03
datetime::tests::bench_datetime_parse_from_rfc3339 242 239 -3 -1.24% x 1.01
This adds a new `std` feature to chrono that is enabled by default. By
deactivating this feature via `default-features = false` you can now use
chrono in applications that don't use the standard library. The `serde`
feature is supported as well.
Resolves#336
The internal, tz-independent timestamp was valid, but since the timezone offset
could change as you add or subtract a second or two you would get
nonsense/nonexistent times when you observed them.
Fixes#318
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.
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.
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.
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.
Brandon W Maister
Michal Srb
Christopher Serr
Samokhin Ilya
Mahmoud Al-Qudsi
Andrei Nesterov
novacrazy
Thomas Bytheway
Toby Dimmick
Jethro Beekman
David Kellum
Kang Seonghoon