Issue #21264 has been updated by 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. ---------------------------------------- Feature #21264: Extract Date library from Ruby repo in the future https://bugs.ruby-lang.org/issues/21264#change-112691 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- 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. 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? -- https://bugs.ruby-lang.org/

Issue #21264 has been updated by 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 '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. ---------------------------------------- Feature #21264: Extract Date library from Ruby repo in the future https://bugs.ruby-lang.org/issues/21264#change-112716 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- 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. 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? -- https://bugs.ruby-lang.org/

Issue #21264 has been updated by 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. ---------------------------------------- Feature #21264: Extract Date library from Ruby repo in the future https://bugs.ruby-lang.org/issues/21264#change-112718 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- 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. 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? -- https://bugs.ruby-lang.org/