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.

[hsbt (Hiroshi SHIBATA)]

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.

Do you mean make all feature of Date class to core class? I prefer @zverok (Victor Shepelev) 's idea that is "simplified" version of Date.

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.

Agreed.

[jeremyevans0 (Jeremy Evans)]

hsbt (Hiroshi SHIBATA) wrote in #note-3:

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.

Do you mean make all feature of Date class to core class? I prefer @zverok (Victor Shepelev) 's idea that is "simplified" version of Date.

I am also OK with a simplified version of Date. I believe the main potential opportunities for simplification are:

• Always assume the Gregorian calendar (no support for date of calendar reform)
• Only store civil dates (year, month, day)
  • Either no support for julian/ordinal/commercial dates (my preference)
  • or calculate them every time they are requested

I think an important question is whether the simplified Date should be ::Date, or something like ::Time::Date. One issue with making the simplified version ::Date is it opens up backwards compatibility issues for code that uses features removed in the simplification. Having the simplified version as a new class allows for gradual code conversion. We could also release a gem that backported the simplified Date for older Ruby versions, to allow code supporting older Ruby versions to work and accelerate ecosystem conversion to simplified Date. The gem would be a no-op on a Ruby version that included the simplified Date. The downsides of a new class is it would likely require changes to code that could potentially work without changes, and it would be uglier.

[zverok (Victor Shepelev)]

I think an important question is whether the simplified Date should be ::Date, or something like ::Time::Date. One issue with making the simplified version ::Date is it opens up backwards compatibility issues for code that uses features removed in the simplification.

I am afraid that ::Time::Date approach is mostly doomed. Assuming you have many instances of Date usage in the codebase (including some not-so-obvious ones, like const_get and deserialization), and the new Ruby version says there is this change, and you have two options:

1. require 'date' (the bundled "old Date") and everything works
2. replace everything with ::Time::Date

People will inevitably mostly choose option 1.

OTOH, the whole point of simplification is "almost nobody uses some parts of Date, so it is not reasonable to keep them in core/maintain".

So, if the new simplified class would be just ::Date, some very small amount of code will break (if it is not so, the Date shouldn't be simplified).

For this case, I'd say

1. We might consider a bundled date library to extend the core (new) Date class with missing functionality (like stdlib time does)...
2. And only if it turns out to be definitely impossible (due to incompatible internal representation), some new name might be introduced.

[jeremyevans0 (Jeremy Evans)]

zverok (Victor Shepelev) wrote in #note-5:

I think an important question is whether the simplified Date should be ::Date, or something like ::Time::Date. One issue with making the simplified version ::Date is it opens up backwards compatibility issues for code that uses features removed in the simplification.

I am afraid that ::Time::Date approach is mostly doomed. Assuming you have many instances of Date usage in the codebase (including some not-so-obvious ones, like const_get and deserialization), and the new Ruby version says there is this change, and you have two options:

1. require 'date' (the bundled "old Date") and everything works
2. replace everything with ::Time::Date

People will inevitably mostly choose option 1.

For code that would be compatible with both simplified Date and stdlib Date, it would be possible to use the new Date by default easily: Date = ::Time::Date. For applications using Date, this could be done at top level. For most libraries that use date, this could be done inside the library's main module. So it is fairly easy to opt-in without forcing s/Date/Time::Date/g.

OTOH, the whole point of simplification is "almost nobody uses some parts of Date, so it is not reasonable to keep them in core/maintain".

So, if the new simplified class would be just ::Date, some very small amount of code will break (if it is not so, the Date shouldn't be simplified).

I agree that percentage-wise, I expect few applications/libraries would break. The question is what happens if you do have code that breaks. How do you fix it? I think we have to have an answer to this. I suppose one option is to rename stdlib Date from ::Date to something else, so that only users that require non-simplified features need to modify their code.

For this case, I'd say

1. We might consider a bundled date library to extend the core (new) Date class with missing functionality (like stdlib time does)...

I considered this, and it would be great if it were possible. However, I'm not sure it is. Stdlib time is quite different in nature than what you are proposing, it only adds some class methods and a few conversion-to-string methods, nothing that requires additional storage.

2. And only if it turns out to be definitely impossible (due to incompatible internal representation), some new name might be introduced.

This was the reason I suggested a new name. If we simplify Date's internal representation, it likely does not contain enough information for stdlib Date to work correctly in all cases.