Date Conversion Functions to and from Character
Functions to convert between character representations and objects of
"Date" representing calendar dates.
as.Date(x, ...) "as.Date"(x, format, ...) "as.Date"(x, origin, ...) "as.Date"(x, tz = "UTC", ...)"format"(x, ...)"as.character"(x, ...)
- An object to be converted.
- A character string. If not specified, it will try
"%Y/%m/%d"on the first non-
NAelement, and give an error if neither works. Otherwise, the processing is via
- a Date object, or something which can be coerced by
as.Date(origin, ...)to such an object.
- a time zone name.
- Further arguments to be passed from or to other methods,
The usual vector re-cycling rules are applied to
format so the answer will be of length that of the longer of the
Locale-specific conversions to and from character strings are used where appropriate and available. This affects the names of the days and months.
as.Date methods accept character strings, factors, logical
NA and objects of classes
"POSIXct". (The last is converted to days by ignoring
the time after midnight in the representation of the time in specified
time zone, default UTC.) Also objects of class
package date) and
package chron). Character strings are processed
as far as necessary for the format specified: any trailing characters
as.Date will accept numeric data (the number of days since an
epoch), but only if
origin is supplied.
as.character methods ignore any
fractional part of the date.
as.charactermethods return a character vector representing the date.
NAdates are returned as
as.Datemethods return an object of class
The default formats follow the rules of the ISO 8601 international
standard which expresses a day as
If the date string does not specify the date completely, the returned
answer may be system-specific. The most common behaviour is to assume
that a missing year, month or day is the current one. If it specifies
a date incorrectly, reliable implementations will give an error and
the date is reported as
NA. Unfortunately some common
implementations (such as glibc) are unreliable and guess at the
Years before 1CE (aka 1AD) will probably not be handled correctly.
Conversion from other Systems
Most systems record dates internally as the number of days since some origin, but this is fraught with problems, including
- Is the origin day 0 or day 1? As the Examples show, Excel manages to use both choices for its two date systems.
- If the origin is far enough back, the designers may show their ignorance of calendar systems. For example, Excel's designer thought 1900 was a leap year (claiming to copy the error from earlier DOS spreadsheets), and Matlab's designer chose the non-existent date of January 0, 0000 (there is no such day), not specifying the calendar. (There is such a year in the Gregorian calendar as used in ISO 8601:2004, but that does say that it is only to be used for years before 1582 with the agreement of the parties in information exchange.)
International Organization for Standardization (2004, 1988, 1997, ...) ISO 8601. Data elements and interchange formats -- Information interchange -- Representation of dates and times. For links to versions available on-line see (at the time of writing) http://www.qsl.net/g1smd/isopdf.htm.
Your system's help pages on
strptime to see
how to specify their formats. Windows users will find no help page
strptime: code based on glibc is used (with
corrections), so all the format specifiers described here are
supported, but with no alternative number representation nor era
available in any locale.
## read in date info in format 'ddmmmyyyy' ## This will give NA(s) in some locales; setting the C locale ## as in the commented lines will overcome this on most systems. ## lct <- Sys.getlocale("LC_TIME"); Sys.setlocale("LC_TIME", "C") x <- c("1jan1960", "2jan1960", "31mar1960", "30jul1960") z <- as.Date(x, "%d%b%Y") ## Sys.setlocale("LC_TIME", lct) z ## read in date/time info in format 'm/d/y' dates <- c("02/27/92", "02/27/92", "01/14/92", "02/28/92", "02/01/92") as.Date(dates, "%m/%d/%y") ## date given as number of days since 1900-01-01 (a date in 1989) as.Date(32768, origin = "1900-01-01") ## 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 ## incorrectly treating 1900 as a leap year. ## So for dates (post-1901) 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 ## (these values come from http://support.microsoft.com/kb/214330) ## Experiment shows that Matlab's origin is 719529 days before ours, ## (it takes the non-existent 0000-01-01 as day 1) ## so Matlab day 734373 can be imported as as.Date(734373, origin = "1970-01-01") - 719529 # 2010-08-23 ## (value from ## http://www.mathworks.de/de/help/matlab/matlab_prog/represent-date-and-times-in-MATLAB.html) ## Time zone effect z <- ISOdate(2010, 04, 13, c(0,12)) # midnight and midday UTC as.Date(z) # in UTC ## these time zone names are common as.Date(z, tz = "NZ") as.Date(z, tz = "HST") # Hawaii