0.5 release planning

[djc]

Tracking issue for the 0.5 release. Blocking issues:

• Avoid panicking in chrono function calls (see Consider refactoring chrono to avoid systematic misuse of panics #815)
  • Rename fallible constructors etc to try_()
  • In general, review _opt() APIs to consider renaming to try_() and use Result instead of Option
• Replace TimeDelta with a thin wrapper around core::time::Duration

Nice to haves:

• Opt-in const APIs that allow error checking at compilation

[djc]

@esheppa anything I forgot? We should probably start linking to specific issues/PRs that we need to get in, divided in two categories: blocking (semver-incompatible changes) and non-blocking (API additions and internal changes).

[esheppa]

There are quite a few attached to the 0.5 milestone as well, including:

Blocking:

• Timezone system changes (add LocalOffset type that stores the timezone name #750, exploration with the timezone trait #830, Wrong output from %Z specifier when using Local::now().format() #749, Consider new helper methods for LocalResult #716)
• Remove old duration references, timedelta (after Use std duration with NaiveTime #895 etc merged)

Non-blocking:

• Adding Day<Tz> (Rename NaiveDate and potentially remove Date<Tz> #820 / add Day<Tz> #883)
• Const improvements (Making Duration::seconds and similar functions const #638, Changes to naive::internals to enable more const functions #882)
• Use core::time::Duration (Use std duration with NaiveTime #895)
• Improved fuzzing etc (Fix building chrono-fuzz #967, Add chrono-fuzz to CI and update its libfuzzer-sys dependency #968, etc)

[howjmay]

I am curious about the progress of #749

[jtmoon79]

And my PRs around string parsing? 😊

• Issue #660 whitespace exact #807
• Constrain timezone parsing #1000
• Issue 835 timezone offset allow MINUS SIGN (U+2212) (branch main) #1001

[djc]

No need to mention PRs that have already been merged. 🙂

[xemwebe]

Is there any topic where you would welcome some help to speed things up to proceed on the 0.5 release?

I maintain a couple of crates which depend on chrono and felt some pressure from users to switch to the time crate due to the vulnerability problems of the latest official release, but I really don't like its interface.

Therefore, I believe my time would be better spend to improve chrono instead of switching to time.

[kpcyrd]

@xemwebe that's a very common problem at this point, you can avoid the vulnerable time dependency of chrono 0.4 like this:

cargo add chrono --no-default-features -F clock

As soon as any crate in your dependency tree depends on chrono with default features it's going to pull in time 0.1 again though.

[djc]

@xemwebe in general, help with all the things already mentioned above would be welcome. I want to make structured attempt to avoid panics and expose fallible API instead in 0.5. Maybe start by having a look at things like #1010 and #974?

[Zomtir]

I hope #996 avoids many of those panics; or at least lays the groundwork. Feedback is welcome!

[xemwebe]

Thanks for the hints, I will probably have a look at #996 with respect to #1010 and #974 to see if I can be of any help.

[xemwebe]

Since @Zomtir focuses on constructors, I would work on prusti issues not related to constructors (i.e. basically #974).
However, I have checked a few of the detected issues and most of them seems to be false positive, i.e. the detected potential overflow could never happen after careful check of the parameters involved. How would you like to deal with these cases? Just add some comment? Mark these function as #[trusted] might go to far if the function is not trivial.