From: shevegen@...
Date: 2018-12-15T21:17:20+00:00
Subject: [ruby-core:90554] [Ruby trunk Misc#15418] Date.parse('2018')

Issue #15418 has been updated by 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,
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.

----------------------------------------
Misc #15418: Date.parse('2018')
https://bugs.ruby-lang.org/issues/15418#change-75704

* Author: foonlyboy (Eike Dierks)
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
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












-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>