Bug #7137

Date.parse overly lenient when attempting to parse Monday?

Added by Gary Weaver over 1 year ago. Updated over 1 year ago.

[ruby-core:47887]
Status:Rejected
Priority:Low
Assignee:tadayoshi funaba
Category:lib
Target version:-
ruby -v:ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux] Backport:

Description

irb(main):001:0> require 'date'
=> true
irb(main):002:0> Date.parse('Monitoring')
=> #
irb(main):003:0> Object.constants.sort.each{|c|puts "#{c}=#{Object.constget(c)}" if c.tos.startwith? 'RUBY'}; nil
RUBY
COPYRIGHT=ruby - Copyright (C) 1993-2012 Yukihiro Matsumoto
RUBYDESCRIPTION=ruby 1.9.3p194 (2012-04-20 revision 35410) [x8664-linux]
RUBYENGINE=ruby
RUBY
PATCHLEVEL=194
RUBYPLATFORM=x8664-linux
RUBYRELEASEDATE=2012-04-20
RUBYREVISION=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!

History

#1 Updated by Zachary Scott over 1 year ago

  • Category set to lib
  • Assignee set to tadayoshi funaba

#2 Updated by tadayoshi funaba over 1 year ago

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

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

#3 Updated by Alexey Muranov over 1 year ago

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

#4 Updated by Shyouhei Urabe over 1 year ago

-1 is not about parsing. Stop messing.

#5 Updated by tadayoshi funaba over 1 year ago

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

#6 Updated by Alexey Muranov over 1 year ago

@tadf 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')
=> #

@shyouhei sorry if the example with -1 was not similar.

#7 Updated by tadayoshi funaba over 1 year ago

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

#8 Updated by Gary Weaver over 1 year ago

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, although I appreciate his help.

@tadf, 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 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

#9 Updated by Matthew Kerwin over 1 year ago

On 15 October 2012 22:48, garysweaver (Gary Weaver)
garysweaver@gmail.com 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, although I appreciate his help.

@tadf, 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 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

#10 Updated by tadayoshi funaba over 1 year ago

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.

#11 Updated by tadayoshi funaba over 1 year ago

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

BigDecimal('five million')
#=> #

Also available in: Atom PDF