Repository navigation
Add padding size to Pad::Zero or Pad::Space #1663
Description
The uu_date command in coreutils uses chrono to parse the format string. In #7334 there is a report that it is needed to add the amount of padding to the format string.
current behavior
let format_items = StrftimeItems::new("+%03d"); will yield Item::Error.
expected behavior
let format_items = StrftimeItems::new("+%03d"); should yield Item::Numeric(Numeric::Day, Pad::Zero(3)).
And in format_numeric() replace the hard coded 1 char padding to the value in Pad::Space or Pad::Zero.
Activity
djc commentedon Feb 24, 2025
Padis public API and I don't want to take a semver-incompatible change for this -- would be open to accomodate this use case within the contraints.BigPapa314 commentedon Feb 24, 2025
Ahh I missed that.
Can you imagine a way to attach the padding width to the Item::Numeric enum without breaking the public API?
djc commentedon Feb 24, 2025
Well,
Numericis declared as#[non_exhaustive]at least, so it's probably possible to smuggle something in there?BigPapa314 commentedon Feb 24, 2025
Hmmm. We could add something like
But that's a hack.
Should I make a proposal or should we wait for 1.0 to add it to the Pad enum.
djc commentedon Feb 25, 2025
I guess we could try whether we can make
Pad#[non_exhaustive](and add a new variant) in a semver-compatible release. It's technically not compatible, but breakage might be pretty rare in practice.BigPapa314 commentedon Feb 25, 2025
Hmm, so what are the implications for dependent code:
Numeric/Padenums are retrieved from chrono and forwarded to chrono again. Like in uu_date.#[non_exhaustive]option.Padand developers might need to init thewidthinformation.I guess there is no default initializer that we could use to init the
widthautomatically to one.#[non_exhaustive].The dependent code has to add the new variants with the
widthfield.widthfield to the current Variant.This might keep the current behavior without taking respect to the
widthinformation.So it seams if we go the
#[non_exhaustive]route there is only one case that is not breaking.What is your experience / opinion here? Did i miss something?
djc commentedon Feb 26, 2025
I don't understand the way you wrote this up.
BigPapa314 commentedon Feb 26, 2025
To sum it up. I'm not sure if the additional complexity of more
PadVariants is justified by the slightly lower breakage potential. What do you think?djc commentedon Feb 28, 2025
Okay, I did a code search and I don't think we can make
Padnon_exhaustiveor add a variant to it without breaking a bunch of code. So I think we have to stick with adding a newNumericvariant for this.I don't know when chrono 0.5 will be released, but I know it won't happen in the near future, so I don't think waiting for a semver-incompatible release is a good option.
BigPapa314 commentedon Mar 3, 2025
Ok. I'll make a proposal.
BigPapa314 commentedon Mar 9, 2025
What do you think about the proposal?