Feature #21264: Extract Date library from Ruby repo in the future

• Status: Open
• Assignee: -
• Target version: -

[hsbt (Hiroshi SHIBATA)]

Note: This is not for Ruby 3.5.

Date and DateTime has no primary maintainer in 10+ years. I would like to deprecate date via bundled gems for reducing our maintenance time especially @nobu (Nobuyoshi Nakada).

But Time.prase and Time.strptime are widely used now. How do we deprecate date library?

1. Migrate Date._strptime, Date.strptime and Date._parse to Time. The current Date is migrated as bundled gems.
2. Migrate Date to the bundled gems. Time.parse and Time.strptime warns if date is not found.
3. Keep the current situation
4. ...

Does anyone have another idea?

[zverok (Victor Shepelev)]

Is it possible to, on the contrary, make Date a core class? Rails, and many other non-Rails codebases I saw, implicitly consider it as such (while kind-of ignoring DateTime, or considering it the "main" time-representing class even when it is only used to represent the modern time periods in a standard Julian calendar, which might add to confusion).

Maybe some "simplified" version of Date (without extended calendar/older dates support), but better integrated with other core classes? Like (Date..Date) === Time support and other similar functionality.

[jeremyevans0 (Jeremy Evans)]

If we are going to remove stdlib Date, I would also prefer that Date be a core class instead of demoted to bundled gems. A large number of Ruby libraries and applications need Date functionality.

I wouldn't be in favor of bringing the entire date library into core. Specifically, I don't think we should bring in DateTime. There were historical reasons for DateTime (especially in Ruby 1.8), but few modern applications would need it.

If we don't want to make Date a core class, since the move to bundled gems seems motivated primarily due to lack of maintainer time, I offer myself as maintainer.