[ruby-core:111569] [Ruby master Bug#19293] The new Time.new(String) API is nice... but we still need a stricter version of this

Issue #19293 has been updated by nobu (Nobuyoshi Nakada).



File time_benchmark.rb added



`Kernel#Integer` may be easier (and probably faster) than the Regexp.

```ruby

Time.new(string) unless Integer(string, exception: false)

```



Benchmark.

```

$ ruby time_benchmark.rb

Warming up --------------------------------------

        active_model    33.895k i/100ms

                time    78.272k i/100ms

Calculating -------------------------------------

        active_model    365.327k (=B1 0.9%) i/s -      1.830M in   5.010500s

                time    943.682k (=B1 1.0%) i/s -      4.775M in   5.060040s

```



BTW, `fast_string_to_time` seems having a bug on the negative offset calcul=
ation.





----------------------------------------

Bug #19293: The new Time.new(String) API is nice... but we still need a str=
icter version of this

https://bugs.ruby-lang.org/issues/19293#change-100936



* Author: matsuda (Akira Matsuda)

* Status: Open

* Priority: Normal

* ruby -v: ruby 3.3.0dev (2023-01-01T07:39:00Z master 542e984d82) +YJIT [ar=
m64-darwin21]

* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN

----------------------------------------

The Ruby 3.2 style `Time.new(String)` API works very well so far, but since=
 the original `Time.new(Integer, Integer, Integer...)` API actually accepts=
 String objects as its arguments, there's one ambiguous case as follows:

`Time.new('20230123')  #=3D> 20230123-01-01 00:00:00 +0900`



Then the problem that I'm facing is that we cannot tell if `Time.new` would=
 parse the given String as ISO8601-ish or just a year, and in order to avoi=
d this ambiguity, we still need to somehow parse the String beforehand in o=
ur application side (like we're doing this way in Ruby on Rails https://git=
hub.com/rails/rails/blob/c49b8270/activemodel/lib/active_model/type/helpers=
/time_value.rb#L64-L70), then dispatch to the new `Time.new` only when the =
String is validated to be conforming the ISO format. Otherwise, if we just =
optimistically pass in given Strings to `Time.new`, we'll occasionally get =
a Time object with an unintended buggy value.



Therefore, it unfortunately seems that my feature request on #16005 still c=
ontinues... I have to keep proposing that we need either of the following:



1. A trustworthy version of ISO8601 parser method perhaps with another name=
 than `.new` that accepts strict ISO8601-ish String only (but with the T de=
limiter, I still don't know what the proper name of this format is).



2. Change `Time.new(Integer-ish, Integer-ish, Integer-ish...)` not to accep=
t Integer-ish Strings but to accept only Integers. But I can imagine that t=
his direction is very unlikely acceptable, due to the incompatibility.



---Files--------------------------------

time_benchmark.rb (1.24 KB)





--=20

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

 ______________________________________________
 ruby-core mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-c=
ore.ml.ruby-lang.org/