Add quarter (%q) date string specifier

[drinkcat]

GNU date supports %q as a date string specifier. This adds support for that in chrono.

This is needed by uutils/coreutils for compability, and would help fix uutils/coreutils#7333.

[codecov]

Codecov Report

Attention: Patch coverage is 93.87755% with 3 lines in your changes missing coverage. Please review.

Project coverage is 91.05%. Comparing base (07216ae) to head (d522b4b).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/format/parsed.rs	89.28%	3 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1666   +/-   ##
=======================================
  Coverage   91.05%   91.05%           
=======================================
  Files          37       37           
  Lines       17359    17402   +43     
=======================================
+ Hits        15806    15846   +40     
- Misses       1553     1556    +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[djc]

(Please squash any further changes into your original commit.)

[djc]

This mostly looks okay -- I think this is missing padding? I wouldn't be surprised if someone wanted to parse or format Q1 as Q01.

[drinkcat]

Padding isn't missing, since this is a length-1 field.

e.g. %q, %_q, %0q all output 2 with GNU date. chrono does the same currently. (%u and %w -- days of the week also behave the same).

What is missing though is the length specifier. GNU date support fields like %2q, %_2q (or %05Y FWIW), but the length specifier isn't supported at all in chrono, AFAICT. I can file another issue for this. The padding issue is tracked in #1663 .

[drinkcat]

Oh, and I'm confused by this:

Merging is blocked
Merge is not an allowed merge method in this repository.
This branch must not contain merge commits.

I did rebase on the lastest main, not sure what's wrong here?!

[drinkcat]

Thanks for the quick review!

[djc]

(Just published 0.4.40 with this change.)

[tustvold]

Just as an FYI this resulted in our arrow-rs builds failing with the latest chrono patch release.

We have codepaths generic on ChronoDateExt + Datelike and this now results in trait ambiguity.

I don't really know if this counts as a breaking change or not... I feel it shouldn't, but it broke our build so maybe it is?? I don't know...

Edit: The official guidance on semver highlights this as a potential issue but says it is up to maintainers to decide - https://doc.rust-lang.org/cargo/reference/semver.html#trait-new-default-item

[djc]

See https://doc.rust-lang.org/cargo/reference/semver.html#trait-new-default-item. In general, with extension traits you're going to be somewhat more likely to be broken, especially if you pick very generic method names.

[tustvold]

So I am a little unsure how best to proceed here, in particular what changes arrow-rs should be making to ensure this doesn't occur again. Other than pinning chrono to a specific patch version, I can't see a tractable way to avoid a reoccurrence?

Switching all callsites to use explicit disambiguation syntax when a chrono trait is in scope is not really a viable option given the extent to which the codebase makes use of traits and generics, and that isn't even considering our downstream consumers...

Maybe it is a case of do nothing now and only do something if it happens again, but I also wonder if chrono might consider not adding new methods to traits in patch releases, especially given how broad its user base is?

[djc]

I wouldn't worry about it too much, I think this will be relatively rare.

[djc]

if chrono might consider not adding new methods to traits in patch releases, especially given how broad its user base is?

I'm not sure this is tenable. Unlike arrow which does regular incompatible releases, chrono is firmly entrenched as low-level library for which semver-incompatible bumps are pretty painful.

[utkarshgupta137]

Sorry for that, maybe you should figure out some fast-track process for this kind of thing. Honestly a three-day process for little patch releases sounds very last decade to me.

Strong +1.

I understand this is a big ask, but would it be possible to revert this change until a new arrow release is made? We've a very complex codebase spanning multiple repositories & adding and maintaining a Cargo.lock everywhere is really difficult for us.

[djc]

If you want to influence the chrono roadmap feel free to contact me for a commercial arrangement. I'm not going to yank this release because your team is unable to manage Cargo.lock files.

[kenaniah]

@djc why not just yank the release and push this as 0.5.0 like semver conventions would suggest?

[djc]

@djc why not just yank the release and push this as 0.5.0 like semver conventions would suggest?

Your understanding of semver conventions as practiced in the crates.io ecosystem seems limited at best, and you seemingly have no idea of the impact of semver-incompatible releases for foundational libraries like chrono. Please take your uninformed "why don't you just" elsewhere.

[Xuanwo]

Sadly it is for legal reasons...

Hi, it is allowed by the ASF to publish hot fixes without a three-day voting period after a public discussion.