R help - Jan 2009 - Unexpected behaviour of the as.Date (was: Error as.Date on Invalid Dates)

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@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@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]]

The first number is the year,
the second is the month and the third is the day.
It ignores trailing characters.
> library(chron)
> f <- function(x) str(month.day.year(as.Date(x)))
> f("2001/1/1")
List of 3
 $ month: num 1
 $ day  : num 1
 $ year : num 2001
> f("1/1/2001")
List of 3
 $ month: num 1
 $ day  : num 20
 $ year : num 1
> # trailing 01 ignored.
> f("13/1/2001")
List of 3
 $ month: num 1
 $ day  : num 20
 $ year : num 13
> # no 13th month
> as.Date("1/13/2001")
Error in fromchar(x) :
  character string is not in a standard unambiguous format

On Thu, Jan 22, 2009 at 1:54 PM, Marie Sivertsen <mariesivert at
gmail.com> wrote:
> 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]]
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>

I believe the original thread was about whether the function returns NA or stops
with an error when given an invalid date (such as Feb 29 in a non-leap year). 
Your question was about how as.Date returned something different from what you
expected.  Related, but different enough that it probably would have been better
to start a new thread.

For your question, the help page for as.Date includes:

  "format: A character string.  The default is
'"%Y-%m-%d"'.  For
          details see 'strftime'."

And 

"Character strings are processed as far as
     necessary for the format specified: any trailing characters are
     ignored."

I don't see anything in your examples that runs counter to the above.

Remember that computers do exactly what you tell them to do, not what you think
that they should do.

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.snow at imail.org
801.408.8111

> -----Original Message-----
> From: r-help-bounces at r-project.org [mailto:r-help-bounces at r-
> project.org] On Behalf Of Marie Sivertsen
> Sent: Thursday, January 22, 2009 11:55 AM
> To: Brian D Ripley; R-help at stat.math.ethz.ch
> Subject: [R] Unexpected behaviour of the as.Date (was: Error as.Date on
> Invalid Dates)
> 
> 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]]
> 
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-
> guide.html
> and provide commented, minimal, self-contained, reproducible code.