Bug #7137: Date.parse overly lenient when attempting to parse Monday?

• Status: Rejected
• Assignee: tadf (tadayoshi funaba)
• Target version: -
• ruby -v: ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

[garysweaver (Gary Weaver)]

irb(main):001:0> require 'date'
=> true
irb(main):002:0> Date.parse('Monitoring')
=> #<Date: 2012-10-08 ((2456209j,0s,0n),+0s,2299161j)>
irb(main):003:0> Object.constants.sort.each{|c|puts "#{c}=#{Object.const_get(c)}" if c.to_s.start_with? 'RUBY'}; nil
RUBY_COPYRIGHT=ruby - Copyright (C) 1993-2012 Yukihiro Matsumoto
RUBY_DESCRIPTION=ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
RUBY_ENGINE=ruby
RUBY_PATCHLEVEL=194
RUBY_PLATFORM=x86_64-linux
RUBY_RELEASE_DATE=2012-04-20
RUBY_REVISION=35410
RUBY_VERSION=1.9.3
=> nil

It's nice that it tries to make sense out of strings liberally, but turning "Monitoring" into "Monday" seems a bit too lenient. Understand the workaround is not to use Date.parse, but I think this is buggy.

Thanks!

[zzak (zzak _)]

• Category set to lib
• Assignee set to tadf (tadayoshi funaba)

[tadf (tadayoshi funaba)]

• Status changed from Open to Rejected
• Priority changed from Normal to 3

it does not function as a validator.
it believes the given date is valid.

[alexeymuranov (Alexey Muranov)]

IMO this is a bug. For example, Math::sqrt(-1) raises an error and does not assume that -1 is 1.

[shyouhei (Shyouhei Urabe)]

-1 is not about parsing. Stop messing.

[tadf (tadayoshi funaba)]

also the following examples should raise error:

Mon Mon Mon
Mon OR Fri?
Good Friday
Friday Sept 11 2001
Sept 11, 2001 & 2002

the original parsedate written by matz.
once, i rewrote the library with a parser generator.
it seems fine, it is strict, but slow.
we decided to back to pattern matching solution.
so i re-rewrote parsedate that the origin of the current parse method.

if we should fix this, we should accept new spec and pay the cost.

see:
http://www.funaba.org/en/date2/manual.html
http://www.funaba.org/date2/parsedate.html

[alexeymuranov (Alexey Muranov)]

@tadf (tadayoshi funaba) thanks for the explanation. Maybe proper parsing is not really a responsibility of Date class. The following also may look surprising:

Date.parse('10/11/12')
=> #<Date: 2010-11-12 ((2455513j,0s,0n),+0s,2299161j)>

@shyouhei (Shyouhei Urabe) sorry if the example with -1 was not similar.

[tadf (tadayoshi funaba)]

i recommend you to use full year.
so, parse method can detect properly except minority middle endian.
sorry if you are minority.
i also recommend you to use internatinal standard format such as iso 8601.
moreover, parse method is just a useful option, you can use strptime method too.

bye

[garysweaver (Gary Weaver)]

I respectfully ask to reopen this ticket. The problem is that people expect that Date.parse('Monitoring') to fail or return nil because it isn't a date nor does it contain anything that should be interpreted as a date. The problem was not the one that Alexey last stated (Date.parse('10/11/12')) which was the stated reason for closing this ticket by @tadf (tadayoshi funaba), although I appreciate his help.

@tadf (tadayoshi funaba), I understand that @matz's solution was to use a pattern matching solution and that this was fastest, but I do not believe that Date.parse('Monitoring') should return Monday. and wonder if @matz (Yukihiro Matsumoto) agrees? Those new to Ruby will use this method thinking that it will work properly, so it would be more helpful if the method were either called Date.guess('Monitoring') or if instead Date.parse were deprecated or flagged compiler warning and in the deprecation or warning message tell people to use strptime instead because Date.parse is too lenient.

Thanks in advance again for considering this change! You guys are awesome!

Gary

[phluid61 (Matthew Kerwin)]

On 15 October 2012 22:48, garysweaver (Gary Weaver)
[e-mail] wrote:

Issue #7137 has been updated by garysweaver (Gary Weaver).

I respectfully ask to reopen this ticket. The problem is that people expect that Date.parse('Monitoring') to fail or return nil because it isn't a date nor does it contain anything that should be interpreted as a date. The problem was not the one that Alexey last stated (Date.parse('10/11/12')) which was the stated reason for closing this ticket by @tadf (tadayoshi funaba), although I appreciate his help.

@tadf (tadayoshi funaba), I understand that @matz's solution was to use a pattern matching solution and that this was fastest, but I do not believe that Date.parse('Monitoring') should return Monday. and wonder if @matz (Yukihiro Matsumoto) agrees? Those new to Ruby will use this method thinking that it will work properly, so it would be more helpful if the method were either called Date.guess('Monitoring') or if instead Date.parse were deprecated or flagged compiler warning and in the deprecation or warning message tell people to use strptime instead because Date.parse is too lenient.

Thanks in advance again for considering this change! You guys are awesome!

Gary

There is an existing equivalence to the lenient pattern matching:
'1xy'.to_i #=> 1

However in the case of converting strings to integers, we have the
option of a validating conversion ..
Integer('1') #=> 1
Integer('1xy') #=> exception
.. or it's trivial to write our own validation rule (i.e. /^\d+$/ )

Dates, however, have much more complex patterns, and I'm unaware of
any existing validating/exception-throwing parser.

If I were to request anything, it would be the option of invoking such
a validating converter that doesn't require a template pattern (as
strptime does), parses and converts the string as Date#parse does, but
tests the entire string, throwing an exception if it is not a
valid/understandable date.

I think we've been spoiled by PHP's strtotime()
http://php.net/manual/en/function.strtotime.php

Matthew Kerwin

[tadf (tadayoshi funaba)]

first of all, i'm not a fan of the current parse method.
you already know the reason.
but, this is not a bug.
if you don't admit this, any discussion is meaningless.
lecture? no thanks.
i already wrote a strict parser at 1999.

[tadf (tadayoshi funaba)]

btw, bigdecimal doesn't validate the given arg.
but, nobody is aware of it.

BigDecimal('five million')
#=> #BigDecimal:8edaba4,'0.0',9(9)