Issue #13072 has been updated by Yui NARUSE.


Victor Shepelev wrote:
> > Time is kept in core
> > date library will be separeted from Ruby repository (stdlib) to date.gem.
> 
> What problems will it solve? Just `date` becoming "not my problem" for core/stdlib maintainers? 
> Date is widely used, and its compatibility with Time (for comparisons, for example) is a huge pain. Being separated into the gem, Date will become incompatible forever (because separate gem definitely can't introduce changes in `Time#<` and similar methods). The situation will be even worse than now.

Date and Time are incompatible both its philosophy, implementation, and API.
If we make Date compatible with Time, it needs Date to introduce incompatible API change.
If so, Date users should just migrate to Time.
Time has enough feature to be migrated from Date. (if not, such feature must be added into Time)

There seems still exist an issue, a class named "Date" for the class which represents date type of RDB.
But I want to discuss about that without current ext/date library.

----------------------------------------
Misc #13072: Current state of date standard library
https://bugs.ruby-lang.org/issues/13072#change-62677

* Author: Victor Shepelev
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
The facts that I've been able to gather (not supported by links, so please forgive me if I am misquoting/misunderstanding):

* date library was initially developed and maintained by Tadayoshi Funaba, who was the "single point of truth" for its design and features;
* for at least year, initial creator/maintainer of the library is inactive in Ruby community, so library mostly considered unmaintained;
* as far as I can "sense"/guess from ticket responses about the library, the core team doesn't see it as crucial/important to maintain.

At the same time, the library provides:

* Widely and extensively used `Date` class;
* Pretty controversial `DateTime` class, which has a huge feature intersection but almost no compatibility with core `Time` class;
* Date parsing functionality (`Date._parse`), which is also used by `lib/time`.

The latter also leads to a really confusing situation, where one of the core Ruby classes has "optional additional functionality" in stdlib.

Overall, the situation looks pretty "dirty" (as in "dirty code"), and seems like needing improvement.

WDYT about this plan (for Ruby 2.5, for ex.):

* make `Date` and `Date._parse` parts of language core (with probably renaming `_parse` to something more readable, or even extracting something like `Date::Parser` module);
* merge `DateTime` and `Time` (while preferring `Time`s interface where possible);
* on the way, gather all requests/bugs from this tracker, related to dates and times parsing, representing and so on.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>