The function Sys.Date() returns a date object, but on different machines running R2.12 I get different outputs
> Sys.Date()
[1] "08/17/2011 00:00:00.000 UTC"
vs.
> Sys.Date()
[1] "2011-08-17"
The former looks like a POSIX object, even though it's still a date object. What possible differences in settings between the two environments may cause this problem?
Could it be that the systems are set to different locales? Try
Sys.getlocale();
Another possible scenario is that some nefarious soul "overwrote" the Sys.Date() function with another. Try running
base::Sys.Date();
on both systems. If you have a package, other than base, that is loading a function called Sys.Date() then you should call base::Sys.Date() to be sure you get the right one.
Related
Using openxlsx package in R. When I run this:
> openxlsx_getOp("dateFormat")
I get the expected value of [1] "yyyy-mm-dd". However, this code:
> op.openxlsx$openxlsx.dateFormat
returns [1] "mm/dd/yyyy".
Why are these different?
EDIT:
Sorry. I called options("openxlsx.dateFormat" = "yyyy-mm-dd") at the top of my source file. Looks like this is important to specify.
From ?op.openxlsx:
‘openxlsx_getOp()’ retrieves the ‘"openxlsx"’ options found in
‘op.openxlsx’. If none are set (currently ‘NULL’) retrieves the
default option from ‘op.openxlsx’. This will also check that the
intended option is a standard option (listed in ‘op.openxlsx’) and
will provide a warning otherwise.
So I suspect it's set to "yyyy-mm-dd" in your environment, hence the discrepancy.
To double check, you can try running R --vanilla on your machine (or the equivalent under Windows) and see if it has reverted back to the default mm/dd/yyyy
As said in the title: Why is there no such function? Or in a different way: What is the type of the function? When I type ?update I get something from stats package, but there is a lubridate function as described here on page 7. There also seems to be a lubridate:::update.Date function, but I can't find any explanations for that function.
Backround: I use the function in a package and I only got it to work after I used the Depends: in the decription file. Initially I wanted to use lubridate::update()...
The lubridate package provides the methods lubridate:::update.Date() and lubridate:::update.POSIXt(). Those functions are not exported into the namespace, but I assume that, by means of function overloading, they are invoked when update() is applied to a POSIXor Date object when the lubridate library is loaded.
The help page ?lubridate:::update.POSIXt provides some information concerning the update function within the lubridate package:
Description
update.Date and update.POSIXt return a date with the specified
elements updated. Elements not specified will be left unaltered.
update.Date and update.POSIXt do not add the specified values to the
existing date, they substitute them for the appropriate parts of the
existing date.
Usage
## S3 method for class 'POSIXt'
update(object, ..., simple = FALSE)
The usage section and the examples in the help page indicate that these functions don't need to be addressed individually, as they are called by simply using update() when the lubridate library is loaded.
To inspect these functions one can type, e.g., lubridate:::update.POSIXt in the console (without passing arguments, and without the parentheses).
You need to load the lubridate package:
library(lubridate)
date <- now()
print(date)
new_date <- update(date, year = 2010, month = 1, day = 1)
print(new_date)
Outputs:
"2016-08-04 08:58:08 CEST"
"2010-01-01 08:58:08 CET"
I'm trying to learn lubridate. The lubridate documentation shows:
date <- ceiling_date(date, "month") - days(1)
[1] "2010-05-31 UTC
for date arithmetic. But if I try
mytoday <- now()
first_of_month <- floor_date(mytoday, "month")
first_of_month_last_year <- first_of_month - years(1)
to use date arithmetic to get the first of the month a year earlier I get an error message
Warning message:
Incompatible methods ("-.POSIXt", "Ops.ordered") for "-"
Any ideas what I'm doing wrong? Thanks.
Ran into the same problem.
In my case it was that I had two date/time related packages installed (chron and lubridate), which appears to conflict with each other to some degree.
I solved this by removing chron as I wasn't really using it.
If you are using multiple date/time related packages, I would suggest removing these packages, then reinstalling them, with lubridate last. However, you may run into other conflicts.
Hope this helps.
I'm using the quantmod package to fetch stock data. The code
Data = getSymbols('LON:ADN',src="google",auto.assign=FALSE, from = '2011-08-10')
Results in an xts as expected, however on closer examination it shows a volume of trades for 2012-10-21 (October 21st) which was a sunday, and is therefore clearly erroneous. Several other sundays are also included. Unfortunately the errors surrounding the weekends seem to have moved the rest of the data out of alignment.
Has anyone experienced similar problems fetching tickers with quantmod before, and if so, are they aware of a way around them?
Thanks
As you mentioned in the comments, this looks like a timezone issue, possibly due to POSIX date conversion in the xts function (see this answer).
I am able to reproduce the issue in a fresh R session when Sys.getenv("TZ") is an empty character string. Setting the timezone to any valid timezone (not all tested), for example, "America/Chicago" yields expected dates, i.e., no Sundays:
In a fresh session (December 16th 2012 was a Sunday):
Sys.getenv("TZ")
# [1] ""
library(quantmod)
Data <- getSymbols('LON:ADN',src="google",auto.assign=FALSE, from = '2011-08-10')
tail(index(Data))
# [1] "2012-12-13" "2012-12-16" "2012-12-17" "2012-12-18" "2012-12-19" "2012-12-20"
Then change the timezone
Sys.setenv(TZ="America/Chicago")
Data <- getSymbols('LON:ADN',src="google",auto.assign=FALSE, from = '2011-08-10')
tail(index(Data))
# [1] "2012-12-14" "2012-12-17" "2012-12-18" "2012-12-19" "2012-12-20" "2012-12-21"
No Sundays.
I'm using strptime(...) in a function of my package. I need to parse a string using specific local settings and used Sys.setlocale as a workaround to get english localization settings. To reduce side effects, the previous local setting is restored afterwards.
The basic code fragment of the function looks as follows:
#parameter settings
sometext <- "Mon, 14 Mar 2011 23:42:16 GMT"
timeFormat <- "%a, %d %b %Y %H:%M:%S"
timeZone <- "GMT"
#get current locale
loc <- Sys.getlocale("LC_TIME")
#set british localization
dummy <- Sys.setlocale("LC_TIME", "en_GB.UTF-8")
#parse datetime string
time <- strptime(sometext, format = timeFormat, tz= timeZone)
#set local back
dummy <- Sys.setlocale("LC_TIME", loc)
Unfortunately, a colleague of mine gets the following warning when using this function:
In Sys.setlocale("LC_TIME", "en_GB.UTF-8") :
OS reports request to set locale to "en_GB.UTF-8" cannot be honored
On my computer everything works fine.
Is there a better (and independent from installed R localization) way of performing this task? Generally I would like to use strptime as it allows a very flexible way of parsing datetime strings.
I am quite sure that the "en_GB.UTF-8" locale is not installed on your college's computer. The easiest way could be to install it :) Well, this is not trivial with every OS.
Other option could be to use a standard locale which can be found on every computer. As your added example shows no special format, you could try with setting LC_TIME to C, which works under Linux and Windows also. With that locale, your given example will work like a charm. See:
> Sys.setlocale("LC_TIME", "C")
> strptime("Mon, 14 Mar 2011 23:42:16 GMT", format = "%a, %d %b %Y %H:%M:%S", tz="GMT")
[1] "2011-03-14 23:42:16 GMT"
Or otherwise you should transform your data - e.g.: write a short function to substitute all week- and months' name to standard strings and restructure your imported strings to standard ones.
I have tried your code on my Windows machine and get the same error. For reference, the results of Sys.getlocale("LC_TIME"):
> Sys.getlocale("LC_TIME")
[1] "English_United Kingdom.1252"
I suspect this might be a fairly standard locale.
But I also suspect that the better way of approaching this problem is to use some of the functions in package lubridate, which makes it easy to work with dates.
You don't give enough details in your question what you are tring to do, but I am guessing that "sometext" is in a specific expected format, such as DMY or YMD. Lubridate provides functions to parse dates in any specified format, e.g. dmy(), ymd(), mdy() - you get the picture.
If you provide more details about your real problem, we might be able to help more specifically.