The new wording tries to make clearer that those methods use a 1-based
numbering scheme.
This commit also includes a couple of drive-by cosmetic changes.
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
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.
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.
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).
- 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`.
- `NaiveDateTime` is now almost completely annotated with examples.
- Introduced `NaiveTime::overflowing_{add,sub}` for the correct
handling of overflow/underflow of `NaiveTime`.
- `NaiveDateTime +/- Duration` operation is rewritten with those
methods, eliminating any problem against leap seconds. (Thus this
is yet another slight breaking change, but considered a bug fix.)
Especially for naives types, methods can be too long to fit in
one line. Previously ad-hoc closures have been used for extreme
cases; this commit will update them to the following form:
use anything::needs::to::be::imported;
let shortened = SomeType::long_name_to_be_shortened;
assert_eq!(shortened(...), ...);
It should be noted that the shortened name is no longer arbitrary;
it should be either the original method name, or when it gets too
long, a name with adjectives and clauses removed. The abbreviation
is now consistent, and restricted to the following:
- `num_days` -> `ndays`; `num_secs` -> `nsecs`
- `hms_milli` -> `hmsm`; - `hms_micro` -> `hmsu`; `hms_nano` -> `hmsn`
The goal is to make examples NOT look alike tests, and more alike
the actual code. (Well, not always possible but I'm trying.)
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.