Unnecessary dependency on chrono

[lffg]

First of all, thanks for your work on this library :-)

At $work, our services depend on the time crate for date/time stuff. There is also the new jiff crate, which will probably gain some popularity in the future. In general, since the Rust ecosystem has many date/time libraries, one could argue that libraries such as bdays should be agnostic over them.

However, that's currently not the case, as the HolidayCalendar trait has a bound restricting the generic type to the chrono Datelike trait. As a solution, bdays could define and expose its own Datelike trait. WDYT?

I may be able to send a PR.

[felipenoris]

That's a thing about Rust.. it does not have date in it's standard library. I had to search for a lib that was popular enough. Personally I don't like the chrono API. bdays does not need datetime, just date, and this concept is not very obvious in chrono. Or, as far as I can remember, it's called NaiveDate, which is kind of a ... naive... naming.

I like the idea of defining a trait. But, then, anyone that would like to use bdays would need to implement that trait in each project that bdays is needed, right?

[lffg]

it does not have date in it's standard library

@felipenoris, indeed. The lack of a more fully-feature standard library is a common pain in Rust.

But, then, anyone that would like to use bdays would need to implement that trait in each project that bdays is needed, right?

Not necessarily! We may use cargo features to make bdays provide built-in integration with the most common date libraries, such as chrono, time, and jiff. The trait (e.g. bdays::Datelike) would always be exposed (under the default feature set), while its implementations for third-party date types (e.g. chrono::NaiveDate, time::Date, etc) would be gated behind a feature specific to the library.

With this design, if some user downloads this crate with the chrono feature, the impl bdays::Datelike for chrono::NaiveDate would be enabled, in a way that downstream users wouldn't have to manually implement it again!

Should we proceed with this design, I should also note that through optional dependencies, a bdays downstream user would not be forced to transitively depend on chrono, time, or jiff. Such a dependency would be enabled only when the feature for the specific upstream crate is enabled.