-
Notifications
You must be signed in to change notification settings - Fork 537
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Absorb the time crate #286
Conversation
Hey, Awesome! Thank you and sorry for the delay. Based on current thinking I would like this to be another crate ( |
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 :) |
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. |
I've discussed this with one of the 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. This enables further refactoring.
The little buggers snuck through.
What's the status on this? |
I would also like to see this being merged. |
I'd like to see this merged too and would be happy to commit some time to working on it. |
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? |
It causes a different _increased_ API when features are _disabled_. It'll be re-added when chronotope#286 is finished
It causes a different _increased_ API when features are _disabled_. It'll be re-added when #286 is finished
Absorb just enough of the time crate that it is no longer required for the clock feature. v0.1 of the time crate is long deprecated, and v0.2 of the crate is a complete rewrite. Vendoring v0.1 allows chrono to control its own destiny. It also means that downstream users that have upgraded to the time v0.2 ecosystem do not wind up with both time v0.1 and v0.2 in the dependency tree. Even with this patch, the dependency on the old time crate remains by default for backwards compatibility. Specifically, the `chrono::Duration` type is a re-export of the `time::Duration` type when the `oldtime` feature is enabled, as it is by default. The intent is that the `oldtime` feature will be removed when chrono v0.5 is released. Supersedes chronotope#286. Fixes chronotope#400.
Absorb just enough of the time crate that it is no longer required for the clock feature. v0.1 of the time crate is long deprecated, and v0.2 of the crate is a complete rewrite. Vendoring v0.1 allows chrono to control its own destiny. It also means that downstream users that have upgraded to the time v0.2 ecosystem do not wind up with both time v0.1 and v0.2 in the dependency tree. Even with this patch, the dependency on the old time crate remains by default for backwards compatibility. Specifically, the `chrono::Duration` type is a re-export of the `time::Duration` type when the `oldtime` feature is enabled, as it is by default. The intent is that the `oldtime` feature will be removed when chrono v0.5 is released. Supersedes chronotope#286. Fixes chronotope#400.
Absorb just enough of the time crate that it is no longer required for the clock feature. v0.1 of the time crate is long deprecated, and v0.2 of the crate is a complete rewrite. Vendoring v0.1 allows chrono to control its own destiny. It also means that downstream users that have upgraded to the time v0.2 ecosystem do not wind up with both time v0.1 and v0.2 in the dependency tree. Even with this patch, the dependency on the old time crate remains by default for backwards compatibility. Specifically, the `chrono::Duration` type is a re-export of the `time::Duration` type when the `oldtime` feature is enabled, as it is by default. The intent is that the `oldtime` feature will be removed when chrono v0.5 is released. Supersedes chronotope#286. Fixes chronotope#400.
Absorb just enough of the time crate that it is no longer required for the clock feature. v0.1 of the time crate is long deprecated, and v0.2 of the crate is a complete rewrite. Vendoring v0.1 allows chrono to control its own destiny. It also means that downstream users that have upgraded to the time v0.2 ecosystem do not wind up with both time v0.1 and v0.2 in the dependency tree. Even with this patch, the dependency on the old time crate remains by default for backwards compatibility. Specifically, the `chrono::Duration` type is a re-export of the `time::Duration` type when the `oldtime` feature is enabled, as it is by default. The intent is that the `oldtime` feature will be removed when chrono v0.5 is released. Supersedes chronotope#286. Fixes chronotope#400.
Absorb just enough of the time crate that it is no longer required for the clock feature. v0.1 of the time crate is long deprecated, and v0.2 of the crate is a complete rewrite. Vendoring v0.1 allows chrono to control its own destiny. It also means that downstream users that have upgraded to the time v0.2 ecosystem do not wind up with both time v0.1 and v0.2 in the dependency tree. Even with this patch, the dependency on the old time crate remains by default for backwards compatibility. Specifically, the `chrono::Duration` type is a re-export of the `time::Duration` type when the `oldtime` feature is enabled, as it is by default. The intent is that the `oldtime` feature will be removed when chrono v0.5 is released. Supersedes chronotope#286. Fixes chronotope#400.
Absorb just enough of the time crate that it is no longer required for the clock feature. v0.1 of the time crate is long deprecated, and v0.2 of the crate is a complete rewrite. Vendoring v0.1 allows chrono to control its own destiny. It also means that downstream users that have upgraded to the time v0.2 ecosystem do not wind up with both time v0.1 and v0.2 in the dependency tree. Even with this patch, the dependency on the old time crate remains by default for backwards compatibility. Specifically, the `chrono::Duration` type is a re-export of the `time::Duration` type when the `oldtime` feature is enabled, as it is by default. The intent is that the `oldtime` feature will be removed when chrono v0.5 is released. Supersedes chronotope#286. Fixes chronotope#400.
Absorb just enough of the time crate that it is no longer required for the clock feature. v0.1 of the time crate is long deprecated, and v0.2 of the crate is a complete rewrite. Vendoring v0.1 allows chrono to control its own destiny. It also means that downstream users that have upgraded to the time v0.2 ecosystem do not wind up with both time v0.1 and v0.2 in the dependency tree. Even with this patch, the dependency on the old time crate remains by default for backwards compatibility. Specifically, the `chrono::Duration` type is a re-export of the `time::Duration` type when the `oldtime` feature is enabled, as it is by default. The intent is that the `oldtime` feature will be removed when chrono v0.5 is released. Supersedes chronotope#286. Fixes chronotope#400.
Absorb just enough of the time crate that it is no longer required for the clock feature. v0.1 of the time crate is long deprecated, and v0.2 of the crate is a complete rewrite. Vendoring v0.1 allows chrono to control its own destiny. It also means that downstream users that have upgraded to the time v0.2 ecosystem do not wind up with both time v0.1 and v0.2 in the dependency tree. Even with this patch, the dependency on the old time crate remains by default for backwards compatibility. Specifically, the `chrono::Duration` type is a re-export of the `time::Duration` type when the `oldtime` feature is enabled, as it is by default. The intent is that the `oldtime` feature will be removed when chrono v0.5 is released. Supersedes chronotope#286. Fixes chronotope#400.
Absorb just enough of the time crate that it is no longer required for the clock feature. v0.1 of the time crate is long deprecated, and v0.2 of the crate is a complete rewrite. Vendoring v0.1 allows chrono to control its own destiny. It also means that downstream users that have upgraded to the time v0.2 ecosystem do not wind up with both time v0.1 and v0.2 in the dependency tree. Even with this patch, the dependency on the old time crate remains by default for backwards compatibility. Specifically, the `chrono::Duration` type is a re-export of the `time::Duration` type when the `oldtime` feature is enabled, as it is by default. The intent is that the `oldtime` feature will be removed when chrono v0.5 is released. Supersedes #286. Fixes #400.
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. |
@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. |
yes, folks who have |
IMO that's still not okay, as you are knowingly pushing out a breaking change. It was (and is) clearly documented that the |
Doesn't seem like chrono even builds by itself:
|
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. |
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. |
This isn't actually the case, we have a shim module in the root of chrono that is called |
wasm only works on new-enough rust that we can unconditionally use the crate keyword in that method, so let's try that. chronotope#286 (comment)
Absorb just enough of the time crate that it is no longer required for the clock feature. v0.1 of the time crate is long deprecated, and v0.2 of the crate is a complete rewrite. Vendoring v0.1 allows chrono to control its own destiny. It also means that downstream users that have upgraded to the time v0.2 ecosystem do not wind up with both time v0.1 and v0.2 in the dependency tree. Even with this patch, the dependency on the old time crate remains by default for backwards compatibility. Specifically, the `chrono::Duration` type is a re-export of the `time::Duration` type when the `oldtime` feature is enabled, as it is by default. The intent is that the `oldtime` feature will be removed when chrono v0.5 is released. Supersedes chronotope#286. Fixes chronotope#400.
Absorb just enough of the time crate that it is no longer required for the clock feature. v0.1 of the time crate is long deprecated, and v0.2 of the crate is a complete rewrite. Vendoring v0.1 allows chrono to control its own destiny. It also means that downstream users that have upgraded to the time v0.2 ecosystem do not wind up with both time v0.1 and v0.2 in the dependency tree. Even with this patch, the dependency on the old time crate remains by default for backwards compatibility. Specifically, the `chrono::Duration` type is a re-export of the `time::Duration` type when the `oldtime` feature is enabled, as it is by default. The intent is that the `oldtime` feature will be removed when chrono v0.5 is released. Supersedes chronotope#286. Fixes chronotope#400.
Absorb just enough of the time crate that it is no longer required for the clock feature. v0.1 of the time crate is long deprecated, and v0.2 of the crate is a complete rewrite. Vendoring v0.1 allows chrono to control its own destiny. It also means that downstream users that have upgraded to the time v0.2 ecosystem do not wind up with both time v0.1 and v0.2 in the dependency tree. Even with this patch, the dependency on the old time crate remains by default for backwards compatibility. Specifically, the `chrono::Duration` type is a re-export of the `time::Duration` type when the `oldtime` feature is enabled, as it is by default. The intent is that the `oldtime` feature will be removed when chrono v0.5 is released. Supersedes chronotope#286. Fixes chronotope#400.
I've discussed this with one of the
time
crate maintainers (Alex Chrichton), andwith 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.