[R] Convert number to Date

[Prof Brian Ripley]

As an example of the perils, Excel actually has two possible origins, 
which you can select as an option but whose default differs by OS. And 
one of them has in fact different origins for dates before and after 
1900-02-28. From the help for as.Date in R-devel:

% http://support.microsoft.com/kb/214330
## Excel is said to use 1900-01-01 as day 1 (Windows default) or
## 1904-01-01 as day 0 (Mac default), but this is complicated by Excel
## thinking 1900 was a leap year.
## So for recent dates from Windows Excel
as.Date(35981, origin="1899-12-30") # 1998-07-05
## and Mac Excel
as.Date(34519, origin="1904-01-01") # 1998-07-05

(the example is from the URL given).

This is the company whose C runtime declares datetimes before 
1970-01-01 as invalid.  But not those in UTC (some versions of glibc 
misread the POSIX standard to say that), but datetimes before 
1970-01-01 08:00:00 in UTC!

On Thu, 25 Mar 2010, Marc Schwartz wrote:

> On Mar 25, 2010, at 5:41 PM, Joshua Wiley wrote:
>
>>> Kind of off the thread a bit, but when I do:
>>>
>>>> as.Date(40182)
>>>
>>> I ***do not*** get "2080-01-06".  Instead I get an error:
>>>
>>> Error in as.Date.numeric(40182) : 'origin' must be supplied
>>>
>>> Am I the only user who gets picked on in this way, or does it
>>> happen to others as well?  The help on as.Date() clearly specifies
>>> that "origin" must be supplied.  So how come Anna got the result that
>>> she did?
>>
>> I also get that error.  I believe there was a thread a few years back
>> discussing the merits of including a default origin, but to my
>> knowledge, it was never implemented, and there is no way to set a
>> default (e.g., through options()).

That is because what was implemented was already an informed choice.

>
> That was actually just recently discussed again, although I think part of it occurred offlist.
>
> The reason is that the use of as.Date() in this context is intended to be used, as is the case here, with dates coming from other applications that have been converted back to a numeric offset from some origin, where it is likely, as is the case here, that the origin will not be the same as R's.
>
> Thus, there is a reasonable argument to be made to compel the user to know the origin in use by the application from which the data was obtained. Otherwise, if the user does not check their data, they will be in trouble.
>
> If one has dates that have come from R and that have been coerced to numeric, for example via data manipulation (eg. using aggregate(), etc.), one only need to re-set the class back to "Date":
>
> # from ?as.Date
> x <- c("1jan1960", "2jan1960", "31mar1960", "30jul1960")
> z <- as.Date(x, "%d%b%Y")
>
>> z
> [1] "1960-01-01" "1960-01-02" "1960-03-31" "1960-07-30"
>
>
> # same as unclass(z)
> y <- as.numeric(z)
>
>> y
> [1] -3653 -3652 -3563 -3442
>
>
> #Note that R's origin is 1970-01-01
>> as.Date(y, origin = "1970-01-01")
> [1] "1960-01-01" "1960-01-02" "1960-03-31" "1960-07-30"
>
>
> However, all you really need is:
>
> class(y) <- "Date"
>
>> y
> [1] "1960-01-01" "1960-01-02" "1960-03-31" "1960-07-30"
>
>
> HTH,
>
> Marc Schwartz
>
> ______________________________________________
> 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.
>

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