Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Update time crate to 0.2 #400

Closed
estk opened this issue Mar 10, 2020 · 9 comments · Fixed by #478
Closed

Update time crate to 0.2 #400

estk opened this issue Mar 10, 2020 · 9 comments · Fixed by #478

Comments

@estk
Copy link

estk commented Mar 10, 2020

No description provided.

@CryZe
Copy link
Contributor

CryZe commented Mar 10, 2020

The problem is that time 0.2 is effectively a completely different crate from time 0.1, so this is not quite that trivial and I think it even lost some functionality.

@estk
Copy link
Author

estk commented Mar 10, 2020

Wow, thanks @CryZe for the ultra fast response. Ya I've looked into it and for sure totally different. Are you thinking you'll proceed with #286 instead?

@quodlibetor
Copy link
Contributor

yeah sorry that we now have time 0.2 showing up next to 0.1 in dep graphs, I'm working on absorbing the time crate without it being a back-compat problem, which mostly means adding a bunch of From implementations and I suppose putting it behind a default-included feature gate.

@quodlibetor
Copy link
Contributor

I'm going to leave this open because people keep re-creating it, but the correct answer is indeed issue 286

@estk
Copy link
Author

estk commented Mar 11, 2020

Roger, thanks for the update, will you link the pr here so I'll get notified when that work is done?

@quodlibetor
Copy link
Contributor

@estk you can subscribe to a single PR/issue by clicking the "subscribe" button on the right column in github, under notifications:
image

you should do that if you care about it, although yeah this issue will also be closed when that's done.

@jhpratt
Copy link

jhpratt commented Apr 19, 2020

@CryZe What behavior is missing that is needed? Obviously I'm biased, but the breadth of the API is pretty similar.

@bpfoley bpfoley mentioned this issue May 22, 2020
Closed
@sheruost
Copy link

I stand with the proposal as time crate 0.1.x cannot be compiled on some target platform (eg. x86_64-unknown-hermit) due to missing internal sys crate.

@Plecra Plecra mentioned this issue Jul 22, 2020
Closed
6 tasks
@Razican
Copy link

Razican commented Aug 21, 2020

A side note, from maintainers of the time crate, written in hyperium/hyper#2139 (comment):

Just to address the concern about additional weight, time 0.3 will have far more aggressive feature flags. The macros will be fully rewritten to be lightweight (eliminating syn and quote) and being a flag. I also recently ran cargo diet to eliminate publishing unnecessary files, though that's not yet published (or even pushed up I believe).

The extra dependency is standback, which compiles down to literally nothing on the most recent stable — its sole purpose is to backport APIs, so all the compiler would have to do it tokenize and determine what compiler is being used via a build script.

I've actually considered putting the arithmetic behind an on-by-default flag, such that no-default-features would essentially leave you with just the struct definitions and inherent methods, nothing else. Formatting will be placed behind a flag in 0.3 as well.

Of course, httpdate is still probably more efficient, given that it's a fixed format. It's pretty difficult to surpass that, I'd imagine. Just throwing this out there to indicate that most of the issues with regard to weight will be improved! Thanks for your work on hyper and everything else.

Maybe it makes sense to use time 0.3?

benesch added a commit to benesch/chrono that referenced this issue Sep 23, 2020
@benesch
Don't require time crate for clock feature
1ad5ae9 
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.
benesch added a commit to benesch/chrono that referenced this issue Sep 23, 2020
@benesch
Don't require time crate for clock feature
b441714 
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.
@benesch benesch mentioned this issue Sep 23, 2020
Merged
2 tasks
benesch added a commit to benesch/chrono that referenced this issue Sep 23, 2020
@benesch
Don't require time crate for clock feature
fac9e45 
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.
benesch added a commit to benesch/chrono that referenced this issue Sep 23, 2020
@benesch
Don't require time crate for clock feature
9cd0a47 
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.
benesch added a commit to benesch/chrono that referenced this issue Sep 23, 2020
@benesch
Don't require time crate for clock feature
0b2311a 
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.
@benesch benesch mentioned this issue Sep 23, 2020
Closed
benesch added a commit to benesch/chrono that referenced this issue Sep 23, 2020
@benesch
Don't require time crate for clock feature
59d7a7c 
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.
benesch added a commit to benesch/chrono that referenced this issue Sep 23, 2020
@benesch
Don't require time crate for clock feature
31b154c 
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.
benesch added a commit to benesch/chrono that referenced this issue Sep 23, 2020
@benesch
Don't require time crate for clock feature
c8cf743 
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.
quodlibetor pushed a commit that referenced this issue Sep 25, 2020
@benesch
Don't require time crate for clock feature (#478)
5115c6f 
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.
@sereinity sereinity mentioned this issue Sep 28, 2020
Closed
pickfire pushed a commit to pickfire/chrono that referenced this issue Jan 22, 2022
@benesch @pickfire
Don't require time crate for clock feature (chronotope#478)
5282f95 
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.
botahamec pushed a commit to botahamec/chrono that referenced this issue May 26, 2022
@benesch @botahamec
Don't require time crate for clock feature (chronotope#478)
aad31d8 
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.
pickfire pushed a commit to pickfire/chrono that referenced this issue Jul 5, 2022
@benesch @pickfire
Don't require time crate for clock feature (chronotope#478)
b605a21 
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Don't require time crate for clock feature benesch/chrono
6 participants
@quodlibetor @estk @Razican @CryZe @jhpratt @sheruost