Unexpected behaviour of the as.Date (was: Error as.Date on Invalid Dates)

library(chron)
f <- function(x) str(month.day.year(as.Date(x)))

f("2001/1/1")

f("1/1/2001")

# trailing 01 ignored.
f("13/1/2001")

# no 13th month
as.Date("1/13/2001")

Dear Brian,

I dont understand what you mean.  The thread was about the as.Date which you
suggested to be used instead of the as.date.  Following your advice I tried
the as.Date and have questions about the observed behaviour, which was
surprising to me.  Is this what you call hijacking?  Do you mean I ought
start a new thread instead?  I thought my question were relevant to the
threads' subject.  I am sorry if it were not.

So here is the questions once again:  why do the as.Date behave as in my
examples below, is this intended?



On Thu, Jan 22, 2009 at 3:55 PM, Brian D Ripley <ripley at stats.ox.ac.uk>wrote:

You've hijacked a thread here.


On Thu, 22 Jan 2009, Marie Sivertsen wrote:

I am relatively new to R, so maybe I am miss something, but I now tried
the a
s.Date now and have problems understanding how it works (or don't work as
it seem).

Brian D Ripley wrote:

On Thu, 22 Jan 2009, Terry Therneau wrote:

One idea is to use the as.date function, for the older (and less

capable) 'date'

class.  This is currently loaded by default with library(survival).  It

re
turns

NA for an invalid date rather than dying.

So does as.Date *if you specify the format* (as you have to with your

as.da
te:

it has a default one):

My examples:

as.Date("2001/1/1")
Works fine
as.Date("1/1/2001")
Prints "1-01-20" ???
as.Date("13/1/2001")
Prints "13-01-20" ???

as.Date("1/13/2001")
Prints error: not in standard unambigous format
It seems that as if both "1/1/2001" and "13/1/2001" were considered by R
to b
e in a standard unambiguous format (or otherwise an error be reported?)
and yet they


are parsed incorrectly according to what one could think is obvious.  It
is a
lso surprizing that not only "13/1/2001" but also "1/2/2001" and
"2/1/2001" are successful but incorrect parsed as if they are unambiguous,
and yet
"13/1/2001" is ambiguous, though there is really just one way to parse it
meaningfully.
I think the strings that are incorrectly parsed should raise errors, and
the last example should be succesful parsed.  What is the reason for the
observed
?

Mvh.
Marie

--
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/<http://www.stats.ox.ac.uk/%7Eripley/>
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

       [[alternative HTML version deleted]]