Compilation issue due to update in `time`

[TobiasDeBruijn]

Due to an update in the time crate, since v0.3.52, the cookie crate no longer compiles:

error[E0061]: this method takes 2 arguments but 1 argument was supplied
   --> /home/tobias/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cookie-0.16.2/src/parse.rs:263:27
    |
263 |     let mut date = format.parse(s.as_bytes())?;
    |                           ^^^^^-------------- argument #2 of type `Option<Parsed>` is missing
    |
note: method defined here
   --> /home/tobias/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/time-0.3.52/src/parsing/parsable.rs:62:12
    |
 62 |         fn parse(&self, input: &[u8], defaults: Option<Parsed>) -> Result<Parsed, error::Parse> {
    |            ^^^^^
help: provide the argument
    |
263 |     let mut date = format.parse(s.as_bytes(), /* Option<Parsed> */)?;
    |                                             ++++++++++++++++++++++

For more information about this error, try `rustc --explain E0061`.
error: could not compile `cookie` (lib) due to 1 previous error

As per the time author, this is on Cookie to fix:

This is due to cookie relying on an internal API. Please report the issue there, as that's where the issue lies. I have never documented the existence of that method, nor have I ever guaranteed anything regarding semver on that front.

Relevant issue on time's GitHub

[EvanCarroll]

If the author of time's issue is that documentation determines support, that's a pretty flimsy ledge to stand on. Obviously, if you have cookie depending on undocumented features the right course of action here is to yank the offending version of time and push out another major-version release of time which changes

1. the behavior to the new desired version,
2. seals the impl because documentation doesn't determine what is a breaking change (even if only by convention).

I look forward to the version of cookie.rs that gates use of time/chrono behind a feature flag.

[neunzehn86]

Yeah, for some reason, that guy is really pissed.
He shuts down any discussion by closing and locking issues.

[Powerbyte7]

@neunzehn86 Having every affected person personally chime in is pointless, and exhausting. It'd be different if people were actually submitting PRs to fix the problem, but it's mostly noise. If you're serious about discussing the versioning approach, don't do it in the heat of the issue. Open source is taken for granted enough already.

[EvanCarroll]

@Powerbyte7 that response only works if you don't close the issue and if you say "patches accepted" welcoming the contribution. Defend developers that say "I agree, but I don't care or don't have time." There isn't a real defense to, "stfu this isn't a problem" (effectively the response) when it's clearly a problem that has broken a large percentage of the ecosystem.

But don't take this wrong, there aren't enough people advocating for communities to chill when shit breaks so I applaud your efforts here. But there is a massive nuance you gotta look for. They're not welcoming the help.

[jhpratt]

Ad hominem attacks are unacceptable.

I clearly stated my position, and it was not "stfu this isn't a problem" as you falsely claim I say. It was (and remains) that cookie is relying on an internal, undocumented API that has never had any stability guarantee. The method used here was not, is not, and will not be visible in rustdoc, which is the fundamental basis for what is considered a stable API.

Constant comments on multiple issues in the time repo accomplishes nothing. Not a single comment beyond the initial report added anything of value. Ask yourself this: what would have been accomplished had I not locked the issues? Clearly nothing.

If you think I'm ignoring feedback, you're wrong. I have been in contact (privately via text) with the maintainer of cargo-semver-checks to report a new manner in which downstream crates can break. No amount of existing tooling would have caught this. I put out a call for funding a couple weeks ago when there was unrelated breakage due to a long-standing bug in the compiler. That was met with absolutely nothing. If there is funding available, I will personally develop the tooling to ensure this sort of breakage is caught before a release, not after. If and when that happens, patches can be made and tooling improved before it ever becomes an issue.

They're not welcoming the help.

There is an open PR that I will be reviewing in the near future. This hasn't even been out for 24 hours.

If you want a quick resolution to issues (or avoiding them altogether), find me funding and stop attacking me personally. Doubly so with false quotes. Perhaps if my time were not wasted responding to attacks on my character or to LLM-generated issue reports, this would already be fixed. Doing that delays fixes and is borderline abusive.

If you truly want to help, stop attacking me, stop wasting me time, and find funding for tooling that can prevent this in the future. Essentially, treat me like a human. I am 100% positive you would not want to be treated the way that you are treating me.

it's clearly a problem that has broken a large percentage of the ecosystem

One crate is not a large percentage.

[brianmay]

Like it or not, some open source maintainers can be abrupt with there responses. Probably because they don't have a lot of time for explanations. And in this case an explanation was given. Then the discussion got diverted talking about RLS and speculation how the mistake in cookie-rs was made.

You could argue that the correct fix is to revert the breaking change, and include it in a future major version release. But that is going to increase the work load on the maintainers. And I doubt it is going to happen. I think the argument is fair enough that these functions were only intended for private use. But is a shame they didn't use Rust's features to make external use a compile error.

What does seem positive is this pull request to ensure people can't accidentally use the internal APIs in the future. time-rs/time#797

That would seem like a really good idea.

[jhpratt]

I have released time v0.3.53 which locks down the sealed traits by leveraging the compiler more than I already was. As part of this, I reverted the change to the parsed method.

I cannot emphasize enough: this rollback is temporary. I do not have a set timeframe for when I'll be removing the unnecessary function, but I absolutely will. For this reason, the cookie crate still needs to be patched — the sooner the better.

[joshka]

I put together a branch with a more complete version of the fix, but I’m not opening it as a PR to avoid adding a third competing PR while #256 and #258 already exist:

https://github.com/joshka/cookie-rs/tree/joshka/avoid-private-time-parsing

The approach avoids relying on time’s internal/non-semver-stable parsed-field API. Instead, it parses each accepted cookie date shape with the documented public API, PrimitiveDateTime::parse(...), then applies the cookie/RFC6265 short-year cutoff (0..=69 -> 2000..=2069, 70..=99 -> 1970..=1999) to the parsed year.

The branch also adds more characterization tests around the behavior:

• cutoff edges: 0, 00, 01, 68, 69, 70, 71, 99
• full-year guard cases to ensure years like 1900, 1970, 1999, 2000, 2069, and 2070 are not treated as short years
• coverage across each accepted date format, including the ANSI-style trailing-year format
• docs explaining the supported explicit formats and the boundary where this is not a full RFC6265 tokenizing cookie-date parser

One intentional tolerance improvement is that the long-weekday dash format now accepts a full year as well as a short year, e.g. Sunday, 06-Nov-1994 08:49:37 GMT in addition to Sunday, 06-Nov-94 08:49:37 GMT. That seems better aligned with the RFC6265 cookie-date shape while still keeping the parser to the crate’s existing explicit format list rather than broadening it to full tokenization.

[jhpratt]

parsed-field API

Assuming you're referring to the Parsed struct, that is guaranteed to be stable. Most situations never need to consider it, but it exists if more thorough control is needed.

[joshka]

@jhpratt I wonder if it may be worth adding a more complete RFC 6265 mode for time parsing similar to the 2822 mode? Happy to throw that your way if you want it, but I see you've said that you didn't want the 1123 parser in time previously, so I don't want to waste your time if that's not something you'd consider.

[joshka]

parsed-field API

Assuming you're referring to the Parsed struct, that is guaranteed to be stable. Most situations never need to consider it, but it exists if more thorough control is needed.

I meant the Parsable::parse call that was the root of the problem here (just poorly explained).