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.
Previously Chrono was mainly tested in UTC (Travis) and UTC+9 (the
maintainer's local time zone), but we have frequently seen bugs that
only appear in time zones behind UTC. This commit makes the test run all
unit tests three times, in different time zones (UTC, UTC+9:30 and
UTC-4 for now---the choice is mostly arbitrary but tries to cover DST
and half-hour offsets for the future). Travis already ran them three
times (for rust-serialize and Serde) so this won't slow the CI down.
Closes#130.
So this is a much delayed major release, but this should not really
change how you use Chrono---only the "required" breakages have been
done (e.g. anything hindering API evolution). The "big" release used to
be 0.3, but due to the dependency changes we are forced to push that to
0.4. I've took this opportunity to push all known planned breaking
changes to 0.3, so this should be quite stable for a moment.
See `CHANGELOG.md` for the full list of changes, but most importantly:
- `chrono::prelude` module has been added for proper glob imports.
- `FixedOffset` is now the official "value" type for time zone offsets.
- Serde 0.9 support has landed, and serialization format used by
rustc-serialize and Serde has been now synchronized.
- Formatting items have been slightly adjusted to be future-proof.
Fixes#126.
The intention was to add newer methods using `std::time::Duration`
to the older names, but it will break the API compatibility anyway.
Better to completely remove them right now.
- Formatting item types are no longer `Copy`.
- `Numeric` and `Fixed` items now have `Internal` variants reserved
for the future expansion. It had been hard to expand the items
without totally breaking the backward compatibility (as per
the API evolution guideline of RFC 1105).
- `Item::Owned{Literal,Space}` for the owned variant of
`Item::{Literal,Space}` has been added.
Closes#76.
This may sound strange, but the final type for the offset "value" was
originally `time::Duration` (returned by `Offset::local_minus_utc`).
This caused a lot of problems becaus adding `Duration` fully interacts
with leap seconds and `Duration` itself is somewhat deprecated.
This commit entirely replaces this role of `Duration` with
`FixedOffset`. So if we had `Offset` and `Duration` to represent
the "storage" offset type and the offset "value" in the past,
we now have `Offset` and `FixedOffset`. Storage-to-value conversion is
called to "fix" the offset---an apt term for the type.
The list of actual changes:
- The time zone offset is now restricted to UTC-23:59:59 through
UTC+23:59:59, and no subsecond value is allowed. As described above,
`FixedOffset` is now fully used for this purpose.
- One can now add and subtract `FixedOffset` to/from timelike values.
Replaces a temporary `chrono::offset::add_with_leapsecond` function.
Datelike & non-timelike values are never affected by the offset.
- UTC and local views to `Date<Tz>` are now identical. We keep
relevant methods for the consistency right now.
- `chrono::format::format` now receives `FixedOffset` in place of
`(Old)Duration`.
- `Offset` now has a `fix` method to resolve, or to "fix" the
"storage" offset (`Offset`) to the offset "value" (`FixedOffset`).
- `FixedOffset::{local_minus_utc, utc_minus_local}` methods are added.
They no longer depend on `Duration` as well.
- Rustc-serialize now uses the same serialization format as Serde.
This also means that the older format (naturally derived from
the internals) is no longer supported.
- Serialization support only existed for rustc-serialize has been
(temporarily) removed. This affects `Date<Tz>` and all individual
time zone types. This does *not* affect `DateTime<Tz>` as it has
individual support per `Tz`.
Please note that this is considered a temporary solution to avoid
stabilizing diverging implementations. Their implementations will
likely be reintroduced later.
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`.