shevegen (Robert A. Heiler) wrote:
On my system ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-linux] I get:
Date.parse('Some random string')
# ArgumentError: invalid date
Date.parse('Repellendus Sint sunt quae molestiae dolor illo inventore ea')
# => #<Date: 2017-09-24 ((2458021j,0s,0n),+0s,2299161j)>
So I assume that the first has changed. I have no idea why the latter works
though - I agree. That is weird, unless it is some hidden time info ... but
to my untrained eyes, it looks like an inconsistency. :D
Given that the behaviour between 2.3.3 and 2.4.x is different in the first
case, I assume that this was not deliberate, so, yep probably a bug.
This isn't a bug, it's the result of the fact that Date.parse has always been deliberately loose in parsing (back to ruby 1.8 at least), and sunt is parsed as Sunday, returning the Sunday for the current week:
require 'date'
puts %w'Repellendus Sint sunt quae molestiae dolor illo inventore ea'.map{|w| [w, (Date.parse(w) rescue nil)].inspect}
["Repellendus", nil]
["Sint", nil]
["sunt", #<Date: 2017-09-24 ((2458021j,0s,0n),+0s,2299161j)>]
["quae", nil]
["molestiae", nil]
["dolor", nil]
["illo", nil]
["inventore", nil]
["ea", nil]
Changing Date.parse to be strict instead of loose would be a significant break to backwards compatibility.
In general, you shouldn't pass random data to Date.parse and expect it to return an error. Date.parse always assumes there is some date information in the string and tries its best to find it, and only raises an error if it can't find any date information.
And if you assume that sunt shouldn't be recognized as Sunday, you should consider cases such as:
Date.parse('2008W50')
=> #<Date: 2008-12-08 ((2454809j,0s,0n),+0s,2299161j)>
Date.parse('SunT2008W50')
=> #<Date: 2008-12-14 ((2454815j,0s,0n),+0s,2299161j)>
Date.parse('SatT2008W50')
=> #<Date: 2008-12-13 ((2454814j,0s,0n),+0s,2299161j)>
Updated by 
Updated by 
Updated by