On Thu, Nov 26, 2009 at 12:08 AM, jim holtman - jholtman at gmail.com <+nabble+miller_2555+9dc9649aca.jholtman#gmail.com at spamgourmet.com> wrote:
An easy way is just to write your own function that will accept "NA", convert it to NA and then call as.Date.
I have written such a function, which has provided the temporary workaround mentioned. ( I am not that lazy yet :-) )
R is a functional language, so write some functions. ?Don't try to overload existing functions with new options that may break a lot of existing code. ?If you have special requirements, then adapt your code to them. ?You would probably have to wait around for a long time before an new option got in, so it is easier to create your own.
I do not mind waiting for the additional functionality (and it is no
longer an immediate need given the workaround). I was attempting to
contribute to the continued enhancement of an open source project.
Since the as.Date() function already defines "standard unambiguous
formats," and since "NA" (and "NaN", "Inf", etc) are not ambiguous
within the transform to their numeric counterparts, it stands to
reason that this is logical behaviour of this function.
I also doubt this enhancement would break moderate-to-well-designed code since:
(1) Existing code would enact a stop() condition based on the
current implementation, forcing error-handling, if any.
(2) Converting "NA" (and "NaN", "inf", etc) is not ambiguous.
Coders feeding such strings should expect their numeric counterparts.
In all likelihood, coders would convert these strings manually in
error-handling code anyway.
I have my solution, but wanted to better the project for use by other
community members. The R Core Development Team is welcome to accept or
ignore the suggestion. I do appreciate the time to discuss this topic,
but will consider the matter closed for my part.
Thanks.