as.Date.character suggestion

The default format="" in as.Date.character is supremely confusing. The
help shows as.Date defined as

## S3 method for class 'character'
     as.Date(x, format = "", ...)

yet the function behaves very differently when format is not specified
and when it is specified to its default:

as.Date("2012-01-01")
[1] "2012-01-01"

as.Date("2012-01-01", format = "")

[1] "2014-08-20"  ### Gives today.


The default setting is never used, because if format is not given,
values "%Y-%m-%d" and "%Y/%m/%d" are tried for it (rather than "").

My suggestion is to leave out the default "" for format in as.Date:

as.Date(x, format, ...)

If this causes a conflict in the S3 dispatching, at least indicate in
the help that the default is never used and the function works
differently if format is specified to its default.

On 20/08/2014, 4:11 PM, Peter Langfelder wrote:

The default format="" in as.Date.character is supremely confusing. The
help shows as.Date defined as

## S3 method for class 'character'
     as.Date(x, format = "", ...)

yet the function behaves very differently when format is not specified
and when it is specified to its default:

as.Date("2012-01-01")
[1] "2012-01-01"

as.Date("2012-01-01", format = "")

[1] "2014-08-20"  ### Gives today.


The default setting is never used, because if format is not given,
values "%Y-%m-%d" and "%Y/%m/%d" are tried for it (rather than "").

My suggestion is to leave out the default "" for format in as.Date:

as.Date(x, format, ...)

If this causes a conflict in the S3 dispatching, at least indicate in
the help that the default is never used and the function works
differently if format is specified to its default.

Wouldn't it be simpler to change the test from

if (missing(format))

to

if (format == "")

?

Duncan Murdoch

That would be my preferred solution, but it would break backwards
compatibility for format="", so others may disagree.

Peter

On Wed, Aug 20, 2014 at 1:18 PM, Duncan Murdoch
<murdoch.duncan at gmail.com> wrote:

On 20/08/2014, 4:11 PM, Peter Langfelder wrote:

The default format="" in as.Date.character is supremely confusing. The
help shows as.Date defined as

## S3 method for class 'character'
     as.Date(x, format = "", ...)

yet the function behaves very differently when format is not specified
and when it is specified to its default:

as.Date("2012-01-01")
[1] "2012-01-01"

as.Date("2012-01-01", format = "")

[1] "2014-08-20"  ### Gives today.


The default setting is never used, because if format is not given,
values "%Y-%m-%d" and "%Y/%m/%d" are tried for it (rather than "").

My suggestion is to leave out the default "" for format in as.Date:

as.Date(x, format, ...)

If this causes a conflict in the S3 dispatching, at least indicate in
the help that the default is never used and the function works
differently if format is specified to its default.

Wouldn't it be simpler to change the test from

if (missing(format))

to

if (format == "")

?

Duncan Murdoch

Could do both to preserve bc...

if(missing(format) || !nchar(format))

On Wed, Aug 20, 2014 at 4:52 PM, Gabriel Becker <gmbecker at ucdavis.edu>
wrote:

Could do both to preserve bc...

if(missing(format) || !nchar(format))

No, the problem is that the function behaves differently when format
is missing than when it equals its default. Removing this difference
necessarily changes behaviour and hence (at least in principle) breaks
backward compatibility.

Peter

Ah, my mistake, I read too fast. (My code is also wrong, embarassingly).

It seems like it's behavior when you pass it "" is simply a bug, then.

Sorry for the noise,

~G

strptime("1-1foo","%m-%d")

On Wed, Aug 20, 2014 at 4:59 PM, Peter Langfelder <
peter.langfelder at gmail.com> wrote:

On Wed, Aug 20, 2014 at 4:52 PM, Gabriel Becker <gmbecker at ucdavis.edu>
wrote:

Could do both to preserve bc...

if(missing(format) || !nchar(format))

No, the problem is that the function behaves differently when format
is missing than when it equals its default. Removing this difference
necessarily changes behaviour and hence (at least in principle) breaks
backward compatibility.

Peter

-- 
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis

	[[alternative HTML version deleted]]

So I think Peter Langfelder is absolutely right, remove the default, which is never used anyway, and possibly update the documentation with a more direct reference to strptime(). This should have near-zero effect on the semantics.