Bug #15776
closedDifference between Time.parse behaviour between 2.6.0 and 2.6.1+
Description
There is currently a major parsing difference ruby 2.6.0 and 2.6.1+ which affects time validation logic.
Ruby 2.6.0p0 (2018-12-25 revision 66547) [x86_64-darwin17] behaviour:
irb(main):001:0> require 'time'
irb(main):002:0> Time.parse('123')
Traceback (most recent call last): (...)
ArgumentError (argument out of range)
Ruby 2.6.1p33 (2019-01-30 revision 66950) [x86_64-darwin17]
irb(main):001:0> require 'time'
=> true
irb(main):002:0> Time.parse('123')
=> 2019-05-03 00:00:00 +0100
Expected behaviour is for Time.parse('123')
to raise an exception because the information provided is not enough to properly parse it.
This is the same behaviour on previous versions of Ruby before 2.6.
I couldn't fine anything new added to the docs for ::parse to explain this change.
Updated by mame (Yusuke Endoh) over 5 years ago
- Related to Bug #15506: ArgumentError on some ordinal dates added
Updated by mame (Yusuke Endoh) over 5 years ago
- Status changed from Open to Assigned
- Assignee set to nobu (Nobuyoshi Nakada)
By bisecting, I found this caused by r66735 which was for [Bug #15506]. I'm unsure what behavior is correct, but I recommend not to depend upon such a behavior of corner cases of Time.parse.
Updated by nobu (Nobuyoshi Nakada) over 5 years ago
- Related to Bug #14860: Time.strptime does not work with Julian dates using %j added
Updated by nobu (Nobuyoshi Nakada) over 5 years ago
It is same as Date.parse
and DateTime.parse
.
Updated by nobu (Nobuyoshi Nakada) over 5 years ago
- Status changed from Assigned to Rejected