Bump chrono to v0.4.23#29709
Conversation
| documentation = "https://docs.rs/solana-tokens" | ||
|
|
||
| [dependencies] | ||
| chrono = { version = "0.4", features = ["serde"] } |
There was a problem hiding this comment.
this Cargo.toml update is unavoidable because of the need to use .with_ymd_and_hms(), which is added in v0.4.23.
Intentionally, I avoided to bump version in other Cargo.tomls to avoid downstream chrono update churn en masse, including solana-sdk. As long as we don't use newer fn like solana-tokens. this should be safe.
Conversely, it looks like users are starting to use chrono v0.4.23: #29109
that said, i think this particular Cargo.toml update should be harmless, considering this crate is virtually unused as other deps: https://crates.io/crates/solana-tokens/reverse_dependencies
There was a problem hiding this comment.
I think maybe I can bump the others in another PR. (I would like to make packages use the same version of deps when they are under the same workspace so I force all of them align to 0.4.22 in my workspace inheritance PR)
| } | ||
| } | ||
| impl DateConfig { | ||
| pub fn new(date: Date<Utc>) -> Self { |
There was a problem hiding this comment.
oh, this is another deprecation other than the move from internal panic in chrono: chronotope/chrono#851
There was a problem hiding this comment.
note that DateConfig isn't used at all as our ci shows this api change affects no other code in our monorepo.
|
@yihau could you review this pr? it looks like you're one of dependabot friends along with @CriesofCarrots (thanks for keeping crate updated, btw). :) i just noticed that @CriesofCarrots is ooo. |
2 participants
(no rush; no need to work on weekend)
Problem
#29196 is blocked on chrono version bump (via
rolling-filecrate, which is newly added there).cc: @apfitzge
Summary of Changes
Update chrono to v0.4.23: https://github.com/chronotope/chrono/releases/tag/v0.4.23
Acoompanied code change is due to
chrono's new deprecations. Basically, it's trying to get rid ofpanic!()even with out-of-range inputs in those deprecated API, forcing users to handle errors gracefully while relieving users from validating complex human's calendar (i think this is sensible, considering it's time library) chronotope/chrono#815. so, although I just lazily resorted to.unwrap()naively, it's completely non-functional-change. ;)