I have a problem with R and short month abbreviations in Windows.
I just updated my PC to Windows 10, the local setting of Windows is in Spanish but R got re-configured in English (I suppose).
I have some data where the Date is in format *"%b %d, %Y"* and in spanish, so if the date is January 1st 2018 it will be written like ***ene 1, 2018***.
Before updating Windows, I didn't have any problem setting the date as:
as.Date("ene 1, 2018", format = "%b %d, %Y")
which in turn returned
"2018-01-01"
as expected.
After the update, I had problems reading this format of dates, so if I looked at sessionInfo() it showed me LC_TIME=C. I changed it to Spanish with Sys.setlocale("LC_TIME","Spanish")
Now, if I write format(as.Date('2018-01-01'), "%b %d, %Y") I get
"ene. 01, 2018"*
(please note that there is a dot after the short month name)
I want to remove the dot in ene. because my dates are writen without dot, so now dates processed gives me NA.
What is a little amusing is that adding Sys.setlocale("LC_TIME","Spanish") in my code and then run it, I get the column of dates fine. But if I run it a second time, I get the NA. So I need to restart R if I want to run the code for a second time to get Dates and reports (using R Markdown) without error.
What configuration should I use? Or is there another solution to this problem?
If I write sessionInfo() I get:
locale: LC_COLLATE=Spanish_Chile.1252 LC_CTYPE=Spanish_Chile.1252
LC_MONETARY=Spanish_Chile.1252 LC_NUMERIC=C LC_TIME=Spanish_Spain.1252
Thanks!
I fixed this with replace, cant find a better solution and im tired af
import locale
listaFechasTeorico2 = list()
locale.setlocale(locale.LC_TIME, "Spanish")
date.strftime('%b-%Y').replace(".","")
Related
I do not know what happened but am getting irritated with this. I am currently in the GMT-8 Time Zone. When I type Sys.Date() it returns the tomorrow's date.
As of now the current date & time is 12/7/17 10:41 PM:
I type Sys.time() and this is what i get:
Sys.time()
[1] "2017-12-08 14:37:22 GMT"
I then try to setup my time zone: Sys.setenv(TZ=Sys.timezone())
It clears without errors... and then I type Sys.Date() again and get
Sys.Date()
[1] "2017-12-08"
It should be 12/7/17 !!
Any help is appreciated.
On my mac system, I saw this with R 3.4.1 after updating to Mac OS 10.13.2:
Sys.time()
[1] "2017-12-08 20:52:01 GMT"
Warning:
In as.POSIXlt.POSIXct(x, tz) :
unknown timezone 'zone/tz/2017c.1.0/zoneinfo/Europe/Berlin'
I could fix that by setting Sys.setenv(TZ = "Europe/Berlin"). Valid timezone names for the US can be found using grep('^US/', OlsonNames(), value = TRUE).
After upgrading to R 3.4.3 I see this:
Sys.time()
[1] "2017-12-08 21:57:15 CET"
Sys.timezone()
#[1] "Europe/Berlin"
So this looks like an issue due to an OS update. In fact, the release notes for R 3.4.3 say this:
A workaround has been added for the changes in location of time-zone
files in macOS 10.13 ‘High Sierra’ and again in 10.13.1, so the
default time zone is deduced correctly from the system setting when R
is configured with --with-internal-tzcode (the default on macOS).
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.
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.
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.