6

I find myself confronted with a problem for which I fail to find a clue to a solution - which makes it very hard to actually deal with it.. Here goes: In R (with R-Studio) I try to create a Date object with the library lubridate:

library(lubridate)
ymd(20161001)

which results in an error:

Error in as.POSIXlt.POSIXct(x, tz) : (converted from warning) unknown timezone 'GMT'

A second run (and any subsequent runs) of the last command yields the correct result:

ymd(20161001)
[1] "2016-01-01"

until I restart my R-session, when again the first run triggers an error. I've checked several settings, but can't find anything changing from the first to the second run. Here's, for instance, the output of my sessionInfo():

R version 3.3.2 (2016-10-31)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1

locale:
[1] LC_COLLATE=Dutch_Netherlands.1252  LC_CTYPE=Dutch_Netherlands.1252    LC_MONETARY=Dutch_Netherlands.1252 LC_NUMERIC=C                      
[5] LC_TIME=Dutch_Netherlands.1252    

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] lubridate_1.6.0

loaded via a namespace (and not attached):
[1] magrittr_1.5  tools_3.3.2   stringi_1.1.2 stringr_1.1.0

Sys.timezone() says [1] "Europe/Berlin", and Sys.getenv('TZ') is empty: ""

I do find others stumbling upon the same warning, such as this blogpost or here, but these problems have to do with times, whereas I would prefer to ignore times altogether, and deal with dates only.

Community
  • 1
  • 1
Taeke
  • 179
  • 5
  • try: `Sys.setlocale("LC_TIME","English")` – Zahiro Mor Feb 09 '17 at 17:54
  • Tnx, but unfortunately that did not work out. Behaviour remains the same. – Taeke Feb 09 '17 at 20:31
  • @Taeke have you found a solution? I am experiencing the same issue with ymd_hms - first call throws the same error, the second call executes perfectly fine. – thatWaterGuy Sep 20 '17 at 20:31
  • No, unfortunately I haven't found a solution yet. If you do find a solution, I'd be glad to hear of it! Sorry for the late response.. – Taeke Oct 20 '17 at 19:04
  • You could try `anytime::anydate(20161001)` which works just fine. `Date` objects do not have timezones so the error really should not occur in the first place... – Dirk Eddelbuettel Nov 20 '17 at 23:40
  • I had exactly the same problem with the lubridate package. After setting my systime `Sys.setenv(TZ='GMT')` I added *tz="GMT"* to dmy `dmy(pulver420w$Date ,tz="GMT")` and everything worked. – MarBlo Feb 10 '18 at 07:15

3 Answers3

0

I was getting the same error today. My code was in an Rmarkdown file set to output as a tufte_html document. I was loading the following packages:

library(lubridate)
library(tidyverse)
library(stringr)
library(extrafont)
library(extrafontdb)
library(tufte)

To get my code working I did the following: First, I got off my company's VPN, suspecting that maybe it was the problem, but I was still getting the error when using my home wifi and no VPN. Next, I updated all my packages but was still getting the error. Then, I shut down my Macbook and rebooted but was still getting the error. Finally, I changed my script to no longer load tidyverse as a whole but instead load:

library(lubridate)
library(tibble)
library(dplyr)
library(readr)
library(extrafont)
library(extrafontdb)
library(tufte)

Then my Rmarkdown file rendered to html without the unknown timezone error. Unfortunately, I cannot pinpoint what exactly fixed the error or why loading parts but not the whole tidyverse seemed to do the trick for me. Did you ever solve your problem?

My session info when it worked:

R version 3.4.2 (2017-09-28)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS High Sierra 10.13.1

Matrix products: default
BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] tufte_0.2       extrafontdb_1.0 extrafont_0.17  stringr_1.2.0  
[5] readr_1.1.1     dplyr_0.7.4     tibble_1.3.4    lubridate_1.7.1

loaded via a namespace (and not attached):
 [1] Rcpp_0.12.13     Rttf2pt1_1.3.4   knitr_1.17       bindr_0.1       
 [5] magrittr_1.5     hms_0.3          R6_2.2.2         rlang_0.1.4     
 [9] tools_3.4.2      htmltools_0.3.6  yaml_2.1.14      rprojroot_1.2   
[13] digest_0.6.12    assertthat_0.2.0 bindrcpp_0.2     glue_1.2.0      
[17] evaluate_0.10.1  rmarkdown_1.8    stringi_1.1.6    compiler_3.4.2  
[21] backports_1.1.1  pkgconfig_2.0.1
Jeremy Allen
  • 61
  • 4
  • Unfortunately, I have not yet solved this problem. Your solution (or should I call it a work-around?) seems rather bizarre to me. I cannot get it to work either; I get the error anyway, whether I load lubridate before the tidyverse, after it, with it, or without it. Seems not to make a difference on my system. As with you, I'm receiving this error on my company's laptop. In the meantime, I did receive a new laptop with updated R / packages. Did not change this behaviour though.. – Taeke Dec 11 '17 at 15:27
0

The answer to this question worked for me.

I added Sys.setenv(TZ='America/Detroit') to my script, for example.

Joshua Rosenberg
  • 4,014
  • 9
  • 34
  • 73
  • I checked with my system, and indeed there is no TZ environment variable available. Unfortunately, setting it does not change the observed behaviour - still getting an `error()` – Taeke Dec 11 '17 at 15:29
0

The solution presented here R error: unknown timezone with as.POSIXct()

In my case, after including Sys.setenv(TZ="America/Lima") at the beginning of the code everything works fine. Please check the list of valid TZ values at https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

JC Riveros
  • 1
  • 1