Due to the backward compatibility we won't be going to remove support
for `time::Duration` in 0.3, and the initial 0.3.0 release won't have
proper `std::time::Duration` support (haven't finalized the logics).
However we will reserve proper names and signatures for the upcoming
`std::time::Duration` support---the "older" duration type will be
referred as "signed" in the names.
- Added a `chrono::prelude` module. This does not have the (old)
`Duration` type reexported, so the documentation has now correctly
replaced all occurrences of `chrono::Duration`. The existing
`chrono::Duration` reexport itself remains for the compatibility.
- Avoided using a plain `Duration` type in the signature, to avoid
any ambiguity.
- Renamed `checked_{add,sub}` to `checked_{add,sub}_signed`.
- Subtraction operator between two instants has been removed and
replaced with `signed_duration_since`. This follows the naming
chosen by `std::time::SystemTime` etc., and the version for newer
`std::time::Duration` will be named to `duration_since`.
This provides examples for most of the constructor-like methods on
`TimeZone`, examples on the various `Offset` impls, and links
`NaiveDateTime` to `TimeZone` so that it's more obvious how you're
supposed to do things.
This is related to #88, which is something that I ran into when I
started using rust-chrono.
While writing documentation tests for NaiveTime it was found that
the addition involving leap seconds is *still* slightly broken.
(A consequence of having less tests, well.) The addition routine
has been rewritten to be explicit about leap seconds while passing
all other tests, so the rewrite does not change the intention.
For a while Chrono's serialization support was barely working,
i.e. usable but never been safe. While it wouldn't cause any memory
unsafety, attacker can fabricate an input that will make most users
confused (e.g. seemingly same Date which doesn't compare equally).
This commit will properly error for those cases.
It was also problematic that the generated rustc-serialize format is
very inefficient, especially for JSON. Due to the backward
compatibillity this commit does NOT fix them (likely to be in 0.3),
but this does try to define the exact format and define tons of
tests to detect any change to the serialization.
There are several remaining problems in the serialization format;
the serde implementation seems good, but it is unable to distinguish
some cases of leap seconds (practically won't matter, but still).
The rustc-serialize implementation would require a massive redesign.
For now, I postpone those issues to 0.3 (what a convenient excuse).
Fixes#42.
In Windows libtime populate `time::Tm` from `SYSTEMTIME`, which
unfortunately does not contain `tm_yday`. It tries to calculate it
from other fields, but... as one can say it is completely wrong.
Since other fields are copied in verbatim we work around this
problem by using a less efficient method.
Fixes#85.
This is due to somewhat ambiguous semantics of `Date`. It cannot
really constructed without an intermediate `DateTime` much like
the removed `Time`, but it is much more useful than `Time` so
we need some reasonable meaning to it. This commit clarifies
that meaning and corrects some problems around it:
- The date itself is timezone-agnostic unless the timezone itself
has an offset equal to or greater than one day. In all current
time zones, the date conversion should be a no-op.
- The date may be attached some offset; that offset should have
been occurred within the corresponding day in either the local
time or the UTC.
- `TimeZone` is free to assign the offset within this constraint.
For convenience, the current `Local` time zone assumes the local
midnight or the UTC midnight.
- `DateTime<Tz>` and `Date<Tz>` is now `Copy`/`Send` when
`Tz::Offset` is `Copy`/`Send`. The implementations for them were
mistakenly omitted. Fixes#25.
- `Local::from_utc_datetime` didn't set a correct offset.
The tests for `Local` were lacking. Fixes#26.
`Time` with an associated time zone is in principle possible, but
in practice it can only meaningfully constructed from an existing
`DateTime`. this makes it hard to implement other operations
natural to `NaiveTime` for `Time` (e.g. `with_*` methods), so
we simply let it go.
migration path: if you *do* happen to use `Time`, don't panic!
every operation possible to `Time` is much more possible to
`NaiveTime`. if you have to deal with a local time, first combine
it with a `NaiveDate`, convert it via `TimeZone::from_local_datetime`
then extract `Time` part again.
this is partly because... we are using the simple name `timestamp`
in the `Parsed` anyway. that value is so widespread enough that
its name can be simply THE timestamp. old methods have been marked
deprecated.
- We have splitted `Offset` into `Offset` and `OffsetState` (name
changes in consideration). The former is used to construct and convert
local or UTC date, and the latter is used to store the UTC offset
inside constructed values. Some offsets are their own states as well.
- This uses lots of associated types which implementation is still in
flux. Currently it crashes with debuginfo enabled. We've temporarily
disabled debuginfo from `Cargo.toml`.
- This technically allows a conversion to the local time, but not yet
tested.
Kang Seonghoon
Richard Petrie
Brandon W Maister
János Illés
Sergey V. Galtsev
Jisoo Park
Dan