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/