[#82706] [Ruby trunk Bug#13851] getting "can't modify string; temporarily locked" on non-frozen instances — cardoso_tiago@...
Issue #13851 has been updated by chucke (Tiago Cardoso).
3 messages
2017/09/07
[#82853] [Ruby trunk Bug#13916] Race condition when sending a signal to a new fork — russell.davis@...
Issue #13916 has been reported by russelldavis (Russell Davis).
3 messages
2017/09/19
[#82892] [Ruby trunk Bug#13921] buffered read_nonblock doesn't work as expected using SSLSocket — cardoso_tiago@...
Issue #13921 has been updated by chucke (Tiago Cardoso).
3 messages
2017/09/20
[ruby-core:82636] [Ruby trunk Misc#13072] Current state of date standard library
From:
se8.and@...
Date:
2017-09-02 17:38:39 UTC
List:
ruby-core #82636
Issue #13072 has been updated by se8 (S辿bastien Durand). My two cents. The best naming I found is from Perl 6. There is **Date** class (for date only) and **DateTime** class (for date + time). https://docs.perl6.org/type/Date https://docs.perl6.org/type/DateTime **Time.date** looks confusing to me. Maybe be it could be worth adding full native timezones support someday too (I know Crystal is planning to do that): https://www.iana.org/time-zones ---------------------------------------- Misc #13072: Current state of date standard library https://bugs.ruby-lang.org/issues/13072#change-66463 * Author: zverok (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>