[ruby-core:121627] [Ruby Feature#21264] Extract Date library from Ruby repo in the future
Issue #21264 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21264: Extract Date library from Ruby repo in the future https://bugs.ruby-lang.org/issues/21264 * 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 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. ---------------------------------------- Feature #21264: Extract Date library from Ruby repo in the future https://bugs.ruby-lang.org/issues/21264#change-112686 * 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). 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 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 '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. ---------------------------------------- Feature #21264: Extract Date library from Ruby repo in the future https://bugs.ruby-lang.org/issues/21264#change-112715 * 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 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. ---------------------------------------- Feature #21264: Extract Date library from Ruby repo in the future https://bugs.ruby-lang.org/issues/21264#change-112717 * 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/
Issue #21264 has been updated by Eregon (Benoit Daloze). Do we have examples of the maintenance overhead to just keep date as a default gem? I would think because it's stable and hasn't changed in a long time that it would need little maintenance. It also seems not prone to many security concerns. From a quick look at https://github.com/ruby/date/pulls?q=is%3Apr+is%3Aclosed it seems mostly automated dependencies updates and few other changes. I recall it used to be pure Ruby but was rewritten as a C extension, maybe that causes more maintenance overhead? ---------------------------------------- Feature #21264: Extract Date library from Ruby repo in the future https://bugs.ruby-lang.org/issues/21264#change-112795 * 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.parse` 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 Eregon (Benoit Daloze). Backlink to a PR `Replace C extension with pure Ruby implementation for Ruby >= 3.3`: https://github.com/ruby/date/pull/155 ---------------------------------------- Feature #21264: Extract Date library from Ruby repo in the future https://bugs.ruby-lang.org/issues/21264#change-116620 * 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.parse` 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 jinroq (Jinroq SAITOH). This is a follow-up to the discussion in [Feature #21264] and the ongoing work in [ruby/date PR #155](https://github.com/ruby/date/pull/155), which replaces the C extension of `date` with a pure Ruby implementation. Some decisions on the PR keep diverging without a conclusion, and I think a few of them would be better decided more broadly rather than by the PR reviewers alone. I'd like to ask everyone for your opinions on the following three points. (Purely implementation-level review comments are being handled on the PR itself.) ### 1. How should we treat the (deprecated) `DateTime` class in the pure Ruby rewrite? `DateTime` is documented as deprecated, and in the discussions so far there has been a preference for using `Time` where possible. My own position is that I do not want to take on maintenance of `DateTime` as part of this pure Ruby rewrite. In review, however, it was stated that any backwards-incompatible `DateTime` behavior must be fixed before merge, and that the other `DateTime` issues should ideally be fixed as well. Fully addressing these effectively means committing to maintain `DateTime`, which I would like to avoid given that it is deprecated. My preference is therefore to keep `DateTime` only to the extent needed to keep it functional, and not to actively fix or maintain it beyond that. I understand this may leave some behavioral differences from the current C extension. Given that `DateTime` is deprecated, is it acceptable to not actively maintain `DateTime` in this rewrite? Or do the committers consider fixing its backwards-incompatible behaviors a hard requirement before this can be merged? ### 2. Can we drop fractional-day support for `Date` and make `Date#day_fraction` return an Integer? Currently a `Date` object can hold a fractional day. For example: ``` d = Date.new(2001, 2, 3) + Rational(1, 2) d.class # => Date d.day_fraction # => (1/2) (Rational) ``` There is agreement in the review that fractional days do not make sense for `Date` (a `Date` is meant to designate a whole day). I would like to drop fractional-day support for `Date`, so that `Date#day_fraction` always returns Integer `0`. This is a backwards-incompatible change: `day_fraction` would no longer return a `Rational`, and `Date` arithmetic with a fractional operand would need newly defined behavior. Is this change acceptable? ### 3. Minimum supported Ruby version The pure Ruby implementation currently targets Ruby >= 3.3. It has been suggested that supporting 3.3+ is fine. I would just like to confirm that Ruby >= 3.3 is an acceptable minimum for the pure Ruby date. Thank you. ---------------------------------------- Feature #21264: Extract Date library from Ruby repo in the future https://bugs.ruby-lang.org/issues/21264#change-118583 * 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.parse` 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). My thoughts on these three issues: 1. DateTime: I think we don't need to optimize performance, but we should not accept known behavioral regressions. If @jinroq does not want to fix DateTime issues, I can look into doing so after Date itself is ready. 2. Fractional-day support: I am in favor of removing support for fractional days. 3. Minimum supported Ruby version: I am in favor of changing the required Ruby version to 3.3 and removing the C extension. The main reason to switch from the C extension to Ruby is to make maintenance easier, and maintaining multiple implementations is certainly not easier. Ruby versions older than 3.3 are out of support, and are likely to want to use the C extension anyway for performance (at least Ruby 3.1 and below). I think before we consider switching, the numerous issues I identified in the Ruby implementation need to be fixed in such a way as to not require rereviewing the entire change (no more rebasing). Links to my reviews: * https://github.com/ruby/date/pull/155#issuecomment-4286060068 * https://github.com/ruby/date/pull/155#issuecomment-4954516527 * https://github.com/ruby/date/pull/155#issuecomment-4986174939 * https://github.com/ruby/date/pull/155#issuecomment-5018954473 ---------------------------------------- Feature #21264: Extract Date library from Ruby repo in the future https://bugs.ruby-lang.org/issues/21264#change-118597 * 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.parse` 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/
participants (5)
-
Eregon (Benoit Daloze) -
hsbt (Hiroshi SHIBATA)
-
jeremyevans0 (Jeremy Evans)
-
jinroq (Jinroq SAITOH)
-
zverok (Victor Shepelev)