RStudio Sys.setenv() does not persist

RStudio IDE
1

Hi
Every time I start a new project in RStudio, I get the following warning message.
Warning messages:
1: In as.POSIXlt.POSIXct(x, tz) :
unknown timezone 'default/America/Los_Angeles'

I am not really sure, how to make the time zone persist in the system settings within RStudio.

I am using RStudio: Version 1.0.153 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13) AppleWebKit/604.1.38 (KHTML, like Gecko)

All my scripts/notebooks now have an additional command Sys.setenv (TZ="America/Los_Angeles) to fix this warning.

Any help appreciated.

Thanks,
-Ravi.

2

Per the documentation for Sys.setenv:

The real fix is to fix your system environment/timezone to something that R understands, I think. However, a Mac person would have to help out with that.

That said, this is one potential situation where a .Rprofile would make sense (as a hacky fix) -- if you create a file named .Rprofile in your home directory with the command Sys.setenv(TZ = "America/Los_Angeles") in it, that would run by default every time you run R.

3

I am running into this problem too when I load a package I am working on. I think it is somehow related to the lubridate package (but I doubt it is causing the problem) but I have been not able to make a reproducible error I can dig into. Look at this example of running lubridate::tz() twice in the console:

lubridate::tz(lubridate::ymd("2016-03-26"))
Error in as.POSIXlt.POSIXct(x, tz) :
(converted from warning) unknown timezone 'default/America/New_York'
lubridate::tz(lubridate::ymd("2016-03-26"))
[1] "UTC"

The first time it produces the unknown timezone and the second time it produce UTC

Once I get time to track it down I'll get back to this thread with what I found but it may be a while.

4

You can set this in your startup R profile (~/.Rprofile), e.g.

Sys.setenv(TZ = "America/Los_Angeles")

Replacing that, of course, with whatever the appropriate time zone is for you. (You could also try setting this in e.g. your ~/.Renviron.)

1 Like
5

Which version of R are you using, @ravikk and @danr? According to this R bug report, it should be fixed in the 3.4.2 release:
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17307

1 Like
6

R version 3.3.2 (2016-10-31) for me

7

I installed version.string R version 3.4.2 (2017-09-28) and still get the same error.

lubridate::tz(lubridate::ymd("2016-03-26"))
Error in as.POSIXlt.POSIXct(x, tz) :
(converted from warning) unknown timezone 'default/America/New_York'
lubridate::tz(lubridate::ymd("2016-03-26"))
[1] "UTC"

8

Here a reprex of it

library("lubridate")
#> 
#> Attaching package: 'lubridate'
#> The following object is masked from 'package:base':
#> 
#>     date
lubridate::tz(lubridate::ymd("2016-03-26"))
#> Warning in as.POSIXlt.POSIXct(x, tz): unknown timezone 'default/America/
#> New_York'
#> [1] "UTC"
lubridate::tz(lubridate::ymd("2016-03-26"))
#> [1] "UTC"

The unknown timezone only appears the first time lubridate::tz is used after loading the package I am working on

9

Wow this thread moves fast.

Sorry I was away at a meeting. I tried different versions of R as well, I would like to POSIT that this issue is a macOS issue, I started noticing it after the new macOS HighSierra update.

10

I'm on HighSierra too

1 Like
11

The bug report Nick reference started by saying it was a macOS issue but finally concluded that it was an R build issue (that hit change in macOS). It said that by building R with the right command line switches the problem would go away. It also said the problem was gone in the current build too :disappointed:

12

Looks like this is still a known bug. See page 60 of the R Installation and Administration PDF:

image
image799×166 24 KB

Not being a macOS guy, I don't know if there's a reasonable way to fix this outside of the .Rprofile option or re-compiling from source.

1 Like
13

I just created an .Rprofile with Sys.setenv(TZ = "America/New_York") in it and now the problem is gone.

Thanks @nick

I guess that this is kind of a hack... @nick do you have any idea what the downsides of using it are?

14

The most obvious downside is that, if you change your computer's timezone, R will still use the old one. It also won't fix other users or system users, so scripts run as root or similar would still throw errors. It looks like you can also put a .Rprofile in the R HOME directory (use R.home() to see where it is), which would execute for all users unless they create their own .Rprofile and put it in their home directory (or a project directory).

Overall, it's a fairly innocent "hack" and probably the most straightforward option until it's fixed by the R project or Apple (can't tell who is actually to blame in this case).

15

Thanks Danr and nick for your help on this. I modified by .Rprofile to fix this issue as well.

16

This will work regardless of location and will persist across sessions (and is OS independent)

find timezone through online api using httr and rgeolocate

setme <- 
"Sys.setenv(TZ='America/New_York') #some default not get any errors
invisible(loadNamespace('rgeolocate'))
invisible(loadNamespace('httr'))
mytz <- rgeolocate::ip_api(httr::content(httr::GET('https://api.ipify.org?format=json'))[1])[['timezone']]
Sys.setenv(TZ=mytz)"

cat(setme,file=file.path(R.home(),'etc/Rprofile.site'),sep='\n')
3 Likes
17

Ravi, Did you use the solution sent by yonicd? It works.

18

Good. We have to then restart R after this file is added to the system.
By the way, is this a standard way to set the timezone for all who have upgraded to HighSierra? If yes we will have to put this in the FAQ for mac installation. Also can't we add this step in the installation process?

19

Checkout the solution posted by yonicd. That seems to be the complete solution.

20

a naive question: run this in R interface or copy to Rprofile? Thank you.