Misc #15418: Date.parse('2018')

• Status: Open
• Assignee: -

[foonlyboy (Eike Dierks)]

Date.parse('2018')
ArgumentError: invalid date

I did expect that to return the same as:
Date.parse('2018-1-1')
=> Mon, 01 Jan 2018

working with dates and times is really weird and complicated,
so it makes sense to be strict with parsing.

I watched this one:
https://www.youtube.com/watch?v=-5wpm-gesOY
He's really coming up with some some crazy test cases.

In ruby this is split between Time and DateTime,
some in the core, some in in the standard lib.

---

Im looking forward for the new version,
let's freeze the strings!

~eike

[shevegen (Robert A. Heiler)]

I can understand you to some extent.

I live in Europe and we tend to use the dd.mm.yyyy notation a lot,
at the least in central europe; so I would have assumed that
Date.parse('2018') would mean Date.parse('01.01.2018'), even
though we did not specify the day and month part there; you wrote
the other example of Date.parse('2018-1-1'), which is more or less
the same as the dd.mm.yyyy part - though of course it omits the
"0" for month and days, and is in yyyy-mm-dd format I think (or
yyyy-dd-mm, I can never remember offhand).

But both of these two variants are close to one another,
whereas for the yyyy format given alone, Date.parse()
yields an error. This may be the technically accurate
way, but I personally also feel that assuming this to
refer to the first day in the first month would be
more convenient.

Note that Time.parse() behaves somewhat similar to Date.parse()
in regards to '2018' - both consider this format to be
incomplete or rather raise an error:

Time.parse '2018' # =>ArgumentError (argument out of range)

Whereas:

Time.parse '01.01.2018' # => 2018-01-01 00:00:00 +0100

Works fine.

What I find more confusing is Time, Date and DateTime altogether
(or was it TimeDate ... ). Perhaps in the long run we can get
some more "streamlined" or "unified" behaviour here but
this will probably take a while; and would also introduce
backwards-incompatible change, so it will have to come past
3.0.

I'd be patient and see for the long term situation, towards ruby
3.0 (at the least for the idea itself), or even past ruby 3.0.

Personally I'd even favour just putting it all into one
"namespace", say Time (or ... Date; I don't mind so much,
except for DateTime, which I simply find odd as name),
but I am not sure if this is easily doable or really worth the
net gain - even though I'd prefer this. But people may have to
change their code and they may ask why, so one has to give a
good answer to these cases too. :)

At any rate, I would be patient here - in the long run there
may be some changes; let's wait and see.

PS: On that note ... not so important either, but it would be
kind of nice to see when Date and when Time and when DateTime
was added to ruby. This is not hugely important but it would
be nice to see how old certain stdlib/core parts of ruby
are; at the least stdlib components. But I digress.