From: "timcraft (Tim Craft)" <noreply@...> Date: 2021-11-12T11:33:24+00:00 Subject: [ruby-core:106036] [Ruby master Feature#18033] Time.new to parse a string Issue #18033 has been updated by timcraft (Tim Craft). Nice performance improvement! In terms of the interface I think it would be confusing to make `Time.new` parse a string: * Using a `.parse` method for parsing is more conventional / less surprising / more intention revealing * Having *both* `.new` and `.parse` would be confusing because it's not clear when to use one or the other, what the trade-offs are etc It feels very unintiutive and not "least surprise". Similarly `Time.parse(...,format: :iso8601)` and `Time.parse_iso8601` feel a bit clunky. Is this awkwardness stemming from trying to fit much functionality into the Time class? It would be more work, but if there was a dedicated ISO8601 module we could shift some responsibility away from the Time class. For example: ``` ISO8601::Time.parse # strictly ISO8601 parsing, returns a Time object ``` This could be extended to encapsulate ISO8601 parsing for other classes: ``` ISO8601::Date.parse ISO8601::Duration.parse ISO8601::TimeInterval.parse ``` The same general pattern could be followed for other formats: ``` RFC3339::Time.parse RFC2822::Time.parse SQL92::Time.parse ``` Each of those methods would have the same signature, so they could be easily interchanged to get varying degrees of strictness or performance. From a naming and readability perspective the names are less surprising, more intention revealing, and very greppable. The higher level `Time.parse` method could potentially delegate to these methods to support parsing a wider range of formats. Each module could also be extended to encapsulate string formatting as an alternative to adding instance methods like #iso8601, #rfc3339 etc. *** An alternative to using the formats as the top level modules would be to invert and nest the modules under the Time classes, for example: ``` Time::ISO8601.parse # instead of ISO8601::Time.parse ``` Same benefits���I'm not sure which would be considered more Ruby-ish? ---------------------------------------- Feature #18033: Time.new to parse a string https://bugs.ruby-lang.org/issues/18033#change-94627 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal ---------------------------------------- Make `Time.new` parse `Time#inspect` and ISO-8601 like strings. * `Time.iso8601` and `Time.parse` need an extension library, `date`. * `Time.iso8601` can't parse `Time#inspect` string. * `Time.parse` often results in unintentional/surprising results. * `Time.new` also about 1.9 times faster than `Time.iso8601`. ``` $ ./ruby -rtime -rbenchmark -e ' n = 1000 s = Time.now.iso8601 Benchmark.bm(12) do |x| x.report("Time.iso8601") {n.times{Time.iso8601(s)}} x.report("Time.parse") {n.times{Time.parse(s)}} x.report("Time.new") {n.times{Time.new(s)}} end' user system total real Time.iso8601 0.006919 0.000185 0.007104 ( 0.007091) Time.parse 0.018338 0.000207 0.018545 ( 0.018590) Time.new 0.003671 0.000069 0.003740 ( 0.003741) ``` https://github.com/ruby/ruby/pull/4639 -- 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>