time crate dependency about cookie-rs HOT 11 CLOSED

I'm not a maintainer, but I'm pretty sure that's something that wouldn't even be feasible. sqlx and async-graphql use the feature flags to enable third-party implementations whereas cookie relies on it in the API itself — basically you couldn't have both enabled at the same time, and the features wouldn't be additive as required by cargo.

There's nothing wrong with using both crates, though I can imagine it may get a little confusing at times.

from cookie-rs.

Coming back to this, how about continuing to use time internally for ergonomics, but removing it from the public API? I don't see how time's Duration that allows negative values is useful for setting max-age. Mabye there's other uses of time types in public API?

from cookie-rs.

In general, time on crates is a maintained/expanded version of std::time. It's got a bunch of helpful functions and methods that std::time doesn't, and it's generally agreed that one should use time over std::time.

from cookie-rs.

In general, time on crates is a maintained/expanded version of std::time.

That's not how I see it; the repository is at rust-lang-deprecated/time and the README says:

This library is no longer actively maintained, but bugfixes will be added (details).

it's generally agreed that one should use time over std::time.

Maybe, but I've never seen that advice.

It's got a bunch of helpful functions

Got it, strptime and strftime. There's no equivalent functionality in std::time.

from cookie-rs.

@SergioBenitez time's repository mentions that chrono should be used instead, as time is no longer maintained.

from cookie-rs.

@jhpratt Certainly, but chrono is a much bigger, much more opinionated crate than we need. That being said, I have no strong opinions on the matter. As long as it is user-friendly, I'm open to migration PRs.

from cookie-rs.

Is it possible to use chrono with this crate? It seems to be the recommendation for other crates like sqlx and async-graphql or at least they support it and document how to use. I'm trying to set the expiry for a cookie and it requires OffsetDateTime which doesn't exist in chrono. Should I use two date time packages to work around this?

If I have an expiry on a redis session, can I ignore the cookie expiry?

from cookie-rs.

@onx2 I actually wound up taking over the time crate shortly after my previous comment. It's now a rough equal to chrono, so no reason to avoid one or the other.

from cookie-rs.

It seems like all the other packages I'm using prefer chrono or at least provide a feature for it. Would it be possible to add the feature for chrono or time to this package? Or if that's something you don't want to do, would you suggest using both time and chrono? For example, async-graphql and sqlx both use chrono.

from cookie-rs.

Got it, thanks for the clarification! I'll use time for this crate and chrono for the others 😄

from cookie-rs.

@jhpratt Certainly, but chrono is a much bigger, much more opinionated crate than we need. That being said, I have no strong opinions on the matter. As long as it is user-friendly, I'm open to migration PRs.

Using different packages makes others write more codes to cast types.

Your cookie-rs keeps small and others' codes got bigger.

I still think excessive pursuit of lightweight is toxic.

from cookie-rs.