Absorb the time crate

[jjpe]

I've discussed this with one of the time crate maintainers (Alex Chrichton), and
with his blessing I've purged the dependency on the deprecated time
crate in favor of folding its code into chrono. See issue #285.

This enables further refactoring.

[quodlibetor]

Hey, Awesome! Thank you and sorry for the delay.

Based on current thinking I would like this to be another crate (chrono-time) inside the chrono organization, that prevents making chrono into even more of a monolith, and would make it possible for us to keep git history etc. If I created that would you be interested in doing some of the integration work?

[jjpe]

I merged the contents into chrono because I figured a lot of the code could ultimately be stripped away (that's the impression I got at the time, at least).

But if you'd have it be a separate crate then sure I'd be willing to do the integration work, with the only caveat being that it would have to wait until middle December due to work demands. It would also be nice to have a way to communicate slightly more directly when I start with that, as you're bound to know much more about chrono than I.

If that's fine with you, then let's do it :)

[quodlibetor]

There is a chrono gitter.im channel linked to from the main README, you can chat in the public channel or DM me! I try to be online as much as possible.

[fenhl]

What's the status on this?

[jedisct1]

I would also like to see this being merged.

[bpfoley]

I'd like to see this merged too and would be happy to commit some time to working on it.

[CryZe]

It might make more sense to look into using time 0.2 instead.

[bpfoley]

It might make more sense to look into using time 0.2 instead.

Doesn't #400 conclude not to update to time 0.2.x and to instead absorb the time crate?

[quodlibetor]

The main goal of this was implemented by #478 , so I'm going to close it. If other features of the time crate are necessary I'm open to considering adding them to chrono.

[jhpratt]

@quodlibetor Keep in mind that the PR you referenced requires a feature flag. Moving existing behavior behind a feature flag is not back-compatible, even if that flag is on by default. That change will almost certainly result in breakage somewhere in what is otherwise a semver-compatible change.

[quodlibetor]

yes, folks who have no-default-features turned on and who were relying on interop between time::Duration and chrono will have to add a feature, the same would have been true with this PR. So far folks have not been too mad about that being the backcompat story in chrono, compared to all the other ways that it strives to maintain backwards-compatibility. If it causes serious problems for folks I can yank 0.4.16 and think through some other way forward.

[jhpratt]

IMO that's still not okay, as you are knowingly pushing out a breaking change. It was (and is) clearly documented that the Duration was the same type, but that's no longer he case. But that's your decision to make, of course. I just know that a number of people have been bit by changes like this in the past.

[CryZe]

Doesn't seem like chrono even builds by itself:

 Compiling chrono v0.4.16
error[E0433]: failed to resolve: use of undeclared type or module `oldtime`
   --> C:\Users\Christopher Serr\.cargo\registry\src\github.com-1ecc6299db9ec823\chrono-0.4.16\src\offset\local.rs:155:27       
    |
155 |         local -= oldtime::Duration::seconds(offset.local_minus_utc() as i64);
    |                           ^^^^^^^^ not found in `oldtime`
    |
help: consider importing one of these items
    |
9   | use Duration;
    |
9   | use wasm_bindgen::__rt::core::time::Duration;
    |

[CryZe]

Seems like wasm specific code in chrono here seems to unconditionally depend on oldtime and I'm not using default-features, so yeah exactly what @jhpratt described broke my crate. Though it would probably fine if the wasm code would be fixed to not depend on that module.

[quodlibetor]

Hm yeah I can fix that. Could you describe exactly what features you're building with? I thought that I tested every possible combination of features but I see that can't be the case.

[quodlibetor]

Seems like wasm specific code in chrono here seems to unconditionally depend on oldtime

This isn't actually the case, we have a shim module in the root of chrono that is called oldtime to match the crate import for when the feature is enabled. This seems like some weird namespacing issue.