The #[cfg(bench)] attribute does not exist and is always false. Lets
define a feature "bench" which can be used to enable benchmarks when
building with nightly.
Deciding between zero-indexed (slightly more reasonable, more compatible with
the outside world) and one-indexed (same indexing as `num_days_from_ce`) seems
not worth it. It's trivial to build `num_days_from_epoch` based on the docs in
`num_days_from_ce`, which punts on the decision and is therefor probably the
right decision.
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
And fail CI in the future if `make readme` isn't run when it is needed.
CC conversation in #185, where the README didn't get updated for a year after
lib.rs was improved.
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.