Confirmation that this *is* an OS-specific problem: A professional
implementation of the POSIX standard (Solaris) gets all of these correct.
Your so-called OS lacks any implementation of strptime, so we borrowed one
from glibc. Unfortunately, that is buggy, even to the extent that
unclass(strp
I have followed with interest the discussion on date handling.
I am no expert in these things; all I want to do is convert a character
vector that has been read into R (and which may contain some erroneous
dates) to a "date format", and then do some work with it [e.g., use it in a
plot].
Classes "P
6:17
> To: Simon Fear
> Cc: [EMAIL PROTECTED]
> Subject: Re: [R] ISOdate() and strptime()
>
>
> Security Warning:
> If you are not sure an attachment is safe to open please contact
> Andy on x234. There are 0 attachments with this message.
>
Thomas Lumley wrote:
On Fri, 14 Nov 2003, Simon Fear wrote:
Is the behaviour of ISOtime() and strptime() determined by ISO
or POSIX standard? Seems not to fit R's "no nannying" policy
at all.
It's determined by your operating system, so you're complaining to the
wrong people.
And since R is w
On Fri, 14 Nov 2003, Simon Fear wrote:
>
> Is the behaviour of ISOtime() and strptime() determined by ISO
> or POSIX standard? Seems not to fit R's "no nannying" policy
> at all. Or maybe it's the future: in version 1.9 will I be able to
> type glm() and have R take a best guess at the model
> spec
People who don't like this behaviour (and particularly those
who dislike it as much as I do), should consider as.date() from
the dates package as an alternative. Gives you a NA if the
specified date is impossible (at least in all the examples given
earlier).
Is the behaviour of ISOtime() and str
On Fri, 14 Nov 2003, RINNER Heinrich wrote:
> Dear R-people!
>
> I am using R 1.8.0, under Windows XP.
> While using ISOdate() and strptime(), I noticed the following behaviour when
> "wrong" arguments (e.g., months>12) are given to these functions:
>
> > ISOdate(year=2003,month=2,day=20) #ok
>
