Possible bug in Date/ParseDate

[Matthew Keene]

I have found what appears to be a bug in either the Date or the
ParseDate standard libraries

The program below

require 'date'
require 'parsedate'

p Time.new
p Date._parse(Time.new.to_s)
p ParseDate.parsedate(Time.new.to_s)

produces the following output:

Sat May 14 23:28:42 AUS Eastern Standard Time 2005
{:zone=>"AUS", :sec=>42, :hour=>23, :wday=>6, :mday=>14, :min=>28,
:mon=>5}
[nil, 5, 14, 23, 28, 42, "AUS", 6]

The output from the ParseDate contains a year of nil (which I know isn't
right), and this seems to be because the _parse method of Date (which is
what ParseDate uses) doesn't return a year key in the hash.


Is there something I'm missing here ? The documentation for these
standard libraries doesn't have any description for either the parsedate
method of ParseDate or the _parse method of Date, so I can't fully tell
if this is working as designed, but it seems unlikely.

What is the procedure for filing a bug for cases like this ?

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Possible bug in Date/ParseDate"

|I have found what appears to be a bug in either the Date or the
|ParseDate standard libraries
|
|The program below
|
|require 'date'
|require 'parsedate'
|
|p Time.new
|p Date._parse(Time.new.to_s)
|p ParseDate.parsedate(Time.new.to_s)
|
|produces the following output:
|
|Sat May 14 23:28:42 AUS Eastern Standard Time 2005
|{:zone=>"AUS", :sec=>42, :hour=>23, :wday=>6, :mday=>14, :min=>28,
|:mon=>5}
|[nil, 5, 14, 23, 28, 42, "AUS", 6]

Date._parse does not recognize long timezone including spaces, such as
"AUS Eastern Standard Time". It is a known limitation. I'm not sure
there is any standard for the timezone format.

matz.

 

[Matthew Keene]

Yukihiro Matsumoto wrote:

Date._parse does not recognize long timezone including spaces, such as
"AUS Eastern Standard Time". It is a known limitation. I'm not sure
there is any standard for the timezone format.

matz.

I thought that this might be the problem, but I guess the question is
why does Time.now produce the date in this format if other standard
libraries can't handle it ? Either Time.now should say

Sat May 14 23:28:42 AET 2005

or the standard libraries should be able to handle it.

In other words, if you say:

puts Time.now #...1
t = Time.now.to_s
time_array = ParseDate.parsedate(t)
puts Time.local(*time_array) #...2

then the puts at 1 and 2 should say the same thing.

What shouldn't happen (IMHO) is this...

Sun May 15 12:48:28 AUS Eastern Standard Time 2005
bug.rb:11:in `local': no implicit conversion from nil to integer
(TypeError)
from bug.rb:11

..which is what actually happens

Just to prove it (mainly to myself - I've only been using Ruby for a
week or two, and I think that you might understand it a little better
than I do ), I tried the following:

time_array = ParseDate.parsedate("Sun May 15 12:48:28 AET 2005")
puts Time.local(*time_array)

which prints

Sun May 15 12:48:28 AUS Eastern Standard Time 2005


So it's this inconsistency that I think is the bug, not the inability of
ParseDate to handle timezones with spaces.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Possible bug in Date/ParseDate"

|I thought that this might be the problem, but I guess the question is
|why does Time.now produce the date in this format if other standard
|libraries can't handle it ?

The time format strings are produced by the function of underlying
operating system, namely strftime(). On the other hand, timezone
parsing function, Date._parse is defined by us in Ruby. Since there's
almost no standard for timezone string format, strftime("%Z") may
return any arbitrary strings, thus we cannot guarantee bi-directional
conversion, unless we implement whole time handling functions from
scratch by ourselves.

If someone has better idea, let us know.

matz.

 

[Matthew Keene]

If someone has better idea, let us know.

matz.

Well, since I was complaining about it I decided to put up instead of
shut up and I've made a fairly simple change to the date/format.rb file
which seems to cope with my particular issue. I was trying to find a
unit test for either ParseDate or Date in the source distribution so
that I could check whether it breaks any other cases. I might be blind,
but I wasn't able to find a test which specifically test either of these
standard libraries. Can anybody point me to a set of tests somewhere
which tests all the expected input types for Date._parse ?

 

[Matthew Keene]

Well, since I was complaining about it I decided to put up instead of
shut up and I've made a fairly simple change to the date/format.rb file
which seems to cope with my particular issue. I was trying to find a
unit test for either ParseDate or Date in the source distribution so
that I could check whether it breaks any other cases. I might be blind,
but I wasn't able to find a test which specifically test either of these
standard libraries. Can anybody point me to a set of tests somewhere
which tests all the expected input types for Date._parse ?

Or at the very least a list of supported date formats ? I'm willing to
write the test suite myself, but it's too hard (for me, anyway) to
reverse engineer all of the supported formats with permutations and
combinations from the raw code. Anybody ?