fix: Use chrono >= 0.4.34, < 0.4.40 to avoid breaking

[Xuanwo]

Which issue does this PR close?

Part of #7209

Rationale for this change

What changes are included in this PR?

Are there any user-facing changes?

[Xuanwo]

cc @alamb and @tustvold for a look, thank you.

[tustvold]

If people may have pinned an older version of chrono, will cargo pick this patch release of arrow and error, or is it smart enough to sort things out?

Wonder if we should use the disambiguification syntax for the backport instead...

Thank you for doing this, I've already spent more time on this chrono nonsense than I hoped to, and have a depressingly long backlog of other work...

Edit: another option would be to just constrain chrono to be less than the borked version... This would likely be the safest option...

[Xuanwo]

If people may have pinned an older version of chrono, will cargo pick this patch release of arrow and error, or is it smart enough to sort things out?

cargo will refuse to build if the user tries to use an old version of chrono since we enforce the user to use >= 0.4.40.

[Xuanwo]

Thank you for doing this, I've already spent more time on this chrono nonsense than I hoped to, and have a depressingly long backlog of other work...

❤️, happy to provide help.

I noticed your discussion with chrono, and in my opinion, the best approach is to use an API like arrow_xxx to prevent this from happening again. Maybe I should start a dicussion for this?

[tustvold]

cargo will refuse to build if the user tries to use an old version of chrono since we enforce the user to use >= 0.4.40.

In which case I think we should either change the constrain in this PR to be < 0.4.40 or use the disambiguification syntax. Otherwise people who have fixed their builds will have them break again.

Maybe I should start a dicussion for this?

Having a discussion is probably good just to surface this, although ultimately if chrono takes the policy it is, we effectively need to use disambiguification syntax for all traits where chrono traits are in scope - as they theoretically could conflict with any other trait in context. In this case the collision was with an extension trait, but theoretically the collisions are possible with any trait defined for both a chrono trait and another trait...

It may be the only pragmatic approach is hope they don't break stuff, what the chrono maintainer effectively suggested, which leaves a bad taste in my mouth but may be the only option.

[Xuanwo]

In which case I think we should either change the constrain in this PR to be < 0.4.40 or use the disambiguification syntax. Otherwise people who have fixed their builds will have them break again.

Oh, I see. You mean we enforce users to use <0.4.40 in 54.2.1 and >=0.4.40 starting from 55.3.0 (the next minor release). The good thing is that users who have already fixed this issue by pinning chrono won't be affected again. That makes sense. Will do.

[Xuanwo]

cc @tustvold, please let me know if this what you want.