Timezones not working since the update to R 4.0.3 #928

rachaelmburke · 2020-10-30T12:01:47Z

I updated R yesterday to version 4.0.3 and now my timezone codes are throwing an error in lubridate.

For example
a <- "1 Sep 2020 1:00pm" #make a string date

This works fine:

library(lubridate)
dmy_hm(a) # returns date as expected

But this doesn't work:

dmy_hm(a, tz="Africa/Blantyre") #this throws an error

I get the error

error in C_force_tz(time, tz = tzone, roll) : 
  CCTZ: Unrecognized output timezone: "Africa/Blantyre"

For what it's worth, some of the three letter time zone abbreviations seem to work

dmy_hm(a, tz="UTC") #works ok
dmy_hm(a, tz="CET") #works fine
dmy_hm(a, tz="EST") #works fine

But no other time zone specification works (have tried "Europe/London" and "Africa/Harare")

I've checked by system time zone

Sys.timezone() #returns "Africa/Blantyre" as expected
OlsonNames()#returns 594 timezone names (including "Africa/Blantyre" and everything else I expected)

I'm not sure what's throwing the issue or if it is specific to lubridate, or something else (?)

The text was updated successfully, but these errors were encountered:

gaborcsardi · 2020-10-30T23:57:25Z

I don't see this with CRAN lubridate, on macOS:

❯ a <- "1 Sep 2020 1:00pm" #make a string date
❯ dmy_hm(a, tz="Africa/Blantyre") #this throws an error
[1] "2020-09-01 13:00:00 CAT"

❯ getRversion()
[1] ‘4.0.3’
❯ Sys.timezone()
[1] "Europe/London"

EDIT: this was on Mojave, possibly only an issue on Catalina?

jjallaire · 2020-10-31T10:50:59Z

I am on Catalina and also unable to repro.

Here was the change in R 4.0.3:

On platforms using configure option --with-internal-tzcode, additional values "internal" and (on macOS only) "macOS" are accepted for the environment variable TZDIR. (See ?TZDIR.)
On macOS, "macOS" is used by default if the system timezone database is a newer version than that in the R installation.

So my guess here is that the error occurs under certain configurations where the MacOS TZ database is corrupted or missing? From the TZDIR docs:

Where R was configured with option --with-internal-tzcode (the default on Windows: recommended on Solaris), the database at file.path(R.home("share"), "zoneinfo") is used by default: file ‘VERSION’ in that directory states the version. That option is also the default on macOS but there whichever is more recent of the system database at ‘/var/db/timezone/zoneinfo’ and that distributed with R is used by default. Environment variable TZDIR can be used to point to a different ‘zoneinfo’ database: value "internal" indicates that the database from the R sources and "macOS" indicates the system database.

@rachaelmburke What is the value of Sys.getenv("TZDIR") on your system? What happens if you do Sys.setenv(TZDIR = "internal") before you run the code? What about with Sys.setenv(TZDIR = "macOS")?

jjallaire · 2020-10-31T14:31:04Z

The problem appears to occur if the TZDIR environment variable is set to either "internal" or "macOS". Here is the minimum reproducible example:

# Running on Mac OS X Catalina (10.15.5) under R 4.0.3 w/ timezone changes

Sys.getenv("TZDIR")
#> [1] ""
lubridate::dmy_hm("1 Sep 2020 1:00pm", tz="Africa/Blantyre")
#> [1] "2020-09-01 13:00:00 CAT"

# Now in a fresh R session:

Sys.setenv(TZDIR = "internal") # (also fails for "macOS")
lubridate::dmy_hm("1 Sep 2020 1:00pm", tz="Africa/Blantyre")
#> Error in C_force_tz(time, tz = tzone, roll): CCTZ: Unrecognized output timezone: "Africa/Blantyre"

jjallaire · 2020-10-31T14:56:44Z

Note that cctz requires that the TZDIR by a path not a special value like "internal": https://github.com/google/cctz/blob/742d370708addf54b79ca1b278198d90977d8a29/src/tzfile.h#L25

adamhsparks · 2020-11-01T09:06:09Z

This bit me as well. I went as far as reinstalling macOS and R on my machine thinking there was something at the OS level that was wrong with my machine since a colleague using Windows 10 couldn't duplicate and it didn't happen on my other Mac. But with fresh installs of Catalina and R 4.0.3 both, this keeps occurring.

gaborcsardi · 2020-11-01T09:10:07Z

@adamhsparks Did you install R from CRAN or from HomeBrew? Can you try to set TZDIR = "" in your ~/.Renviron file?

adamhsparks · 2020-11-01T09:14:27Z

R was installed using the Homebrew cask version of R, not the Homebrew formulae.

gsiemon · 2020-11-01T09:14:49Z

I'm seeing this issue to on R4.0.3. R4.0.2 on the same system doesn't have this issue.

Note that if I run @jjallaire's reprex above I get an error but he doesn't on the same code. Also if I run Sys.getenv("TZDIR") after executing the lubridate statement you can see that the environment variable has been set to "macOS".

> Sys.getenv("TZDIR")
[1] ""
> 
> lubridate::dmy_hm("1 Sep 2020 1:00pm", tz="Africa/Blantyre")
Error in C_force_tz(time, tz = tzone, roll) : 
  CCTZ: Unrecognized output timezone: "Africa/Blantyre"
> 
> Sys.getenv("TZDIR")
[1] "macOS"

Setting TZDIR to internal doesn't seem to help either.

> Sys.getenv("TZDIR")
[1] ""
> Sys.setenv(TZDIR="internal")
> Sys.getenv("TZDIR")
[1] "internal"
> 
> lubridate::dmy_hm("1 Sep 2020 1:00pm", tz="Africa/Blantyre")
Error in C_force_tz(time, tz = tzone, roll) : 
  CCTZ: Unrecognized output timezone: "Africa/Blantyre"
> 
> Sys.getenv("TZDIR")
[1] "internal"

Full disclosure I am testing MacOS 11 on this system. Both 11.0.0 Beta 10 and 11.0.1 Beta 1 have this issue. @jjallaire I note you aren't on the latest Catalina which I think is 10.15.7. Perhaps something has changed in later macOS builds that causes things to break?

R is installed from CRAN.

Adding an explicity TZDIR = "" or TZDIR = "internal" to .Renviron results in the same output.

This does not occur on Windows or Ubuntu 20.04.

adamhsparks · 2020-11-01T09:17:36Z

I also tried setting TZDIR = "" in my .Renviron. Sys.getenv("TZDIR") still reports "macOS".

gaborcsardi · 2020-11-01T09:22:07Z

Another idea: can you try setting it as

TZDIR="/Library/Frameworks/R.framework/Resources/share/zoneinfo/"

in ~/.Renviron?

If it is still set to macOS after a restart, then you can try setting it in ~/.Rprofile:

Sys.setenv("TZDIR" = "/Library/Frameworks/R.framework/Resources/share/zoneinfo/")

gsiemon · 2020-11-01T09:25:48Z

@gaborcsardi Your suggestion to set TZDIR to "/Library/Frameworks/R.framework/Resources/share/zoneinfo/"
in .Renviron seems to work!

> Sys.getenv("TZDIR")
[1] "/Library/Frameworks/R.framework/Resources/share/zoneinfo/"
> 
> lubridate::dmy_hm("1 Sep 2020 1:00pm", tz="Africa/Blantyre")
[1] "2020-09-01 13:00:00 CAT"
> 
> Sys.getenv("TZDIR")
[1] "/Library/Frameworks/R.framework/Resources/share/zoneinfo/"
>

gaborcsardi · 2020-11-01T09:50:23Z

FWIW, I don't see this issue on Big Sur, fully updated according to the update manager, the R 4.0.3 installer from CRAN, and CRAN lubridate. TZDIR is not set by default here.

adamhsparks · 2020-11-01T10:02:30Z

Yes, confirming, setting TZDIR="/Library/Frameworks/R.framework/Resources/share/zoneinfo/" in .Renviron works for my own computer.

Now, what's the best method to deal with this error in a package that uses lubridate if it occurs on another user's machine?

gaborcsardi · 2020-11-01T10:17:07Z

Now, what's the best method to deal with this error in a package that uses lubridate if it occurs on another user's machine?

I think this will be probably fixed in lubridate. Until then a workaround would be to wrap calls to lubridate, and in the wrapper set TZDIR to the fixed path (file.path(R.home(), "share", "zoneinfo")), and then reset TZDIR in on.exit(). This can be tedious, though. Also it might not work if people don't use the CRAN installer, but an R version that was configured without the internal time zone DB.

adamhsparks · 2020-11-01T10:21:40Z

Thank you, @gaborcsardi! I suspected it would be fixed in lubridate. We're not in a hurry to publish the package. I think that I can just keep an eye out for that fix and require that version and if need be implement what you have suggested here.

domq · 2020-11-02T10:58:56Z

Not sure whether I am on crack or what, but I reinstalled 4.0.3 on Oct, 21 and afaict everything was working great then.

Now that the winter timezone is upon us (in Europe/Zurich), I am starting having the issue as well! Could the two be linked? (This would also explain why the issue cropped up only three days ago)

Just a thought.

adamhsparks · 2020-11-02T11:01:14Z

I tried it again in the office today on my Mac there that also has Catalina and R4.0.3. No worries.

We don't do DST here in Qld, so no time change for me (at the beginning of October), but could still be related?

gaborcsardi · 2020-11-02T11:09:08Z

I would think that it is related macOS updates, and some versions of the macOS timezone DB are buggy. Actually, not really buggy, they are just more recent than the ones on other macOS versions/updates, and R decides to use them and sets TZDIR to a value that breaks lubridate/cctz.

FWIW these are my versions on Mojave, these work fine with R:

❯ ls -l /var/db/timezone/
total 0
lrwxr-xr-x  1 root  wheel   35 May  9 09:08 icutz@ -> /var/db/timezone/tz/2020a.1.0/icutz
drwxr-xr-x  4 root  wheel  128 Oct 29 08:57 tz/
lrwxr-xr-x  1 root  wheel   29 Oct 29 08:57 tz_latest@ -> /var/db/timezone/tz/2020d.1.0
lrwxr-xr-x  1 root  wheel   38 May  9 09:08 zoneinfo@ -> /var/db/timezone/tz/2020a.1.0/zoneinfo

(I don't really understand why the two versions are mixed here.)

gsiemon · 2020-11-02T11:23:17Z

Interesting...

On my broken setup I see this...

>ls -l /var/db/timezone                                   
total 0
lrwxr-xr-x  1 root  wheel  35  1 Nov 14:31 icutz -> /var/db/timezone/tz/2020d.1.0/icutz
drwxr-xr-x  3 root  wheel  96 30 Oct 09:55 tz
lrwxr-xr-x  1 root  wheel  29 27 Oct 21:23 tz_latest -> /var/db/timezone/tz/2020d.1.0
lrwxr-xr-x  1 root  wheel  38  1 Nov 14:31 zoneinfo -> /var/db/timezone/tz/2020d.1.0/zoneinfo

adamhsparks · 2020-11-02T11:27:51Z

My (broken machine) matches @gsiemon's broken setup.

❯ ls -l /var/db/timezone/                                                                        
total 0
lrwxr-xr-x 1 root wheel 35 Oct 31 22:02 icutz -> /var/db/timezone/tz/2020d.1.0/icutz
drwxr-xr-x 3 root wheel 96 Oct 31 21:26 tz
lrwxr-xr-x 1 root wheel 29 Oct 31 21:26 tz_latest -> /var/db/timezone/tz/2020d.1.0
lrwxr-xr-x 1 root wheel 38 Oct 31 22:02 zoneinfo -> /var/db/timezone/tz/2020d.1.0/zoneinfo

gaborcsardi · 2020-11-02T11:29:51Z

Yeah, small sample, but it seems that if zoneinfo links to a newer tz db, that will make R set TZDIR incorrectly.

gsiemon · 2020-11-02T11:40:37Z

I've just been back to my Timemachine backup and the timezone versions updated from 2020a.1.0 to 2020d.1.0 on October 27. I didn't install any updates then so I'm guessing this was pushed from Apple's end. That seems to reconcile others saying that R4.0.3 was working fine and then it suddenly stopped working.

Files with differences between the two versions:

>diff -rq ./2020a.1.0/ /var/db/timezone/tz/2020d.1.0
Files ./2020a.1.0/icutz/icutz44l.dat and /var/db/timezone/tz/2020d.1.0/icutz/icutz44l.dat differ
Files ./2020a.1.0/versions.plist and /var/db/timezone/tz/2020d.1.0/versions.plist differ
Files ./2020a.1.0/zoneinfo/+VERSION and /var/db/timezone/tz/2020d.1.0/zoneinfo/+VERSION differ
Files ./2020a.1.0/zoneinfo/Africa/Algiers and /var/db/timezone/tz/2020d.1.0/zoneinfo/Africa/Algiers differ
Files ./2020a.1.0/zoneinfo/Africa/Casablanca and /var/db/timezone/tz/2020d.1.0/zoneinfo/Africa/Casablanca differ
Files ./2020a.1.0/zoneinfo/Africa/El_Aaiun and /var/db/timezone/tz/2020d.1.0/zoneinfo/Africa/El_Aaiun differ
Files ./2020a.1.0/zoneinfo/America/Dawson and /var/db/timezone/tz/2020d.1.0/zoneinfo/America/Dawson differ
Files ./2020a.1.0/zoneinfo/America/Whitehorse and /var/db/timezone/tz/2020d.1.0/zoneinfo/America/Whitehorse differ
Files ./2020a.1.0/zoneinfo/Antarctica/Casey and /var/db/timezone/tz/2020d.1.0/zoneinfo/Antarctica/Casey differ
Files ./2020a.1.0/zoneinfo/Antarctica/Macquarie and /var/db/timezone/tz/2020d.1.0/zoneinfo/Antarctica/Macquarie differ
Files ./2020a.1.0/zoneinfo/Asia/Gaza and /var/db/timezone/tz/2020d.1.0/zoneinfo/Asia/Gaza differ
Files ./2020a.1.0/zoneinfo/Asia/Hebron and /var/db/timezone/tz/2020d.1.0/zoneinfo/Asia/Hebron differ
Files ./2020a.1.0/zoneinfo/Canada/Yukon and /var/db/timezone/tz/2020d.1.0/zoneinfo/Canada/Yukon differ
Files ./2020a.1.0/zoneinfo/Europe/Budapest and /var/db/timezone/tz/2020d.1.0/zoneinfo/Europe/Budapest differ
Files ./2020a.1.0/zoneinfo/Europe/Monaco and /var/db/timezone/tz/2020d.1.0/zoneinfo/Europe/Monaco differ
Files ./2020a.1.0/zoneinfo/Europe/Paris and /var/db/timezone/tz/2020d.1.0/zoneinfo/Europe/Paris differ
Files ./2020a.1.0/zoneinfo/Pacific/Fiji and /var/db/timezone/tz/2020d.1.0/zoneinfo/Pacific/Fiji differ
Only in ./2020a.1.0/zoneinfo/US: Pacific-New
Files ./2020a.1.0/zoneinfo/leapseconds and /var/db/timezone/tz/2020d.1.0/zoneinfo/leapseconds differ

Most of these just look like routine timezone updates. I'm happy to send through anything that piques your interest.

Edit: I've just reread your post @gaborcsardi. That makes a lot of sense. Newer TZ data causes switch from internal to macOS TZ data and somehow everything breaks.

rachaelmburke · 2020-11-02T11:56:26Z

Hi... so glad it's not just me!

Sorry to disrupt a "issue" / patch thread with what's now a support question.... but is there any chance someone could explain to me a work around that I can use in the mean time until this get fixed

I can't quite work out how to set or change anything in R.environ or .Rprofile to change TZDIR.

I'm on Catalina 10.15.4

I'm a doctor turned stats / epidemiology person. Learning more all the time about how my computer actually works, but definitely a newbie here. And I have a lot of code for an ongoing project that now doesn't work so well!

Thanks,

Rachael

adamhsparks · 2020-11-02T11:59:47Z

usethis::edit_r_profile() will open it for you and let you edit the file. You just need to restart RStudio after saving

…

Sent from my iPhone

On 2 Nov 2020, at 21:56, Rachael Burke ***@***.***> wrote: Hi... so glad it's not just me! Sorry to disrupt a "issue" / patch thread with what's now a support question.... but is there any chance someone could explain to me a work around that I can use in the mean time until this get fixed I can't quite work out how to set or change anything in R.environ or .Rprofile to change TZDIR. I'm a doctor turned stats / epidemiology person. Learning more all the time about how my computer actually works, but definitely a newbie here. And I have a lot of code for an ongoing project that now doesn't work so well! Thanks, Rachael — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

rachaelmburke · 2020-11-02T12:05:07Z

Amazing - thank you @adamhsparks (and everyone else). Fixed for now!

vspinu · 2020-11-02T14:29:31Z

I don't see this as lubridate specific but if you can think of a simple and reliable way to detect TZDIR on mac then I think it would be ok to include it in this onLoad snippet.

vspinu · 2020-11-02T14:31:16Z

Would be also good to know where exactly those strange "internal" ans "MacOS" values are set and by whom.

mj-ramirez · 2020-11-02T21:26:57Z

Hm, on macOS HighSierra: CCTZ: Invalid timezone of the input vector: "" since this morning.
MJR-Mac-Pro:~ $ ls -l /var/db/timezone/
total 0
lrwxr-xr-x 1 root wheel 35 Nov 2 08:43 icutz -> /var/db/timezone/tz/2020d.1.0/icutz
drwxr-xr-x 3 root wheel 96 Nov 2 08:44 tz
lrwxr-xr-x 1 root wheel 29 Oct 29 08:48 tz_latest -> /var/db/timezone/tz/2020d.1.0
lrwxr-xr-x 1 root wheel 38 Nov 2 08:43 zoneinfo -> /var/db/timezone/tz/2020d.1.0/zoneinfo

my "/Library/Frameworks/R.framework/" is empty ..... cannot find anywhere else...

changing lubridate commands to as.Posix Rbase does not make a difference

* [#928] Call Sys.timezone() onLoad

trifle · 2020-11-25T16:36:09Z

Perhaps as an additional datapoint, this bug is inconsistent across different timezones for me:

> lubridate::dmy_hm("1 Sep 2020 1:00pm", tz="Africa/Blantyre")
[1] "2020-09-01 13:00:00 CAT"
> lubridate::dmy_hm("1 Sep 2020 1:00pm", tz="Europe/London")
[1] "2020-09-01 13:00:00 BST"
> lubridate::dmy_hm("1 Sep 2020 1:00pm", tz="Europe/Berlin")
Error in C_force_tz(time, tz = tzone, roll) : 
  CCTZ: Unrecognized output timezone: "Europe/Berlin"

Some TZs work, while others don't, with no apparent pattern.

session info

``` > devtools::session_info() ─ Session info ────────────────────────────────────────────────────────────────── setting value version R version 4.0.3 (2020-10-10) os macOS Big Sur 10.16 system x86_64, darwin17.0 ui RStudio language (EN) collate en_US.UTF-8 ctype en_US.UTF-8 tz Europe/Berlin date 2020-11-25

─ Packages ──────────────────────────────────────────────────────────────────────
package * version date lib source
assertthat 0.2.1 2019-03-21 [1] CRAN (R 4.0.2)
backports 1.2.0 2020-11-02 [1] CRAN (R 4.0.2)
broom 0.7.2 2020-10-20 [1] CRAN (R 4.0.2)
callr 3.5.1 2020-10-13 [1] CRAN (R 4.0.2)
cellranger 1.1.0 2016-07-27 [1] CRAN (R 4.0.2)
cli 2.2.0 2020-11-20 [1] CRAN (R 4.0.2)
colorspace 2.0-0 2020-11-11 [1] CRAN (R 4.0.3)
crayon 1.3.4 2017-09-16 [1] CRAN (R 4.0.2)
curl 4.3 2019-12-02 [1] CRAN (R 4.0.1)
DBI 1.1.0 2019-12-15 [1] CRAN (R 4.0.2)
dbplyr 2.0.0 2020-11-03 [1] CRAN (R 4.0.2)
desc 1.2.0 2018-05-01 [1] CRAN (R 4.0.2)
devtools 2.3.2 2020-09-18 [1] CRAN (R 4.0.2)
digest 0.6.27 2020-10-24 [1] CRAN (R 4.0.2)
dplyr * 1.0.2 2020-08-18 [1] CRAN (R 4.0.2)
ellipsis 0.3.1 2020-05-15 [1] CRAN (R 4.0.2)
fansi 0.4.1 2020-01-08 [1] CRAN (R 4.0.2)
farver 2.0.3 2020-01-16 [1] CRAN (R 4.0.2)
forcats * 0.5.0 2020-03-01 [1] CRAN (R 4.0.2)
fs 1.5.0 2020-07-31 [1] CRAN (R 4.0.2)
generics 0.1.0 2020-10-31 [1] CRAN (R 4.0.2)
ggplot2 * 3.3.2 2020-06-19 [1] CRAN (R 4.0.2)
glue 1.4.2 2020-08-27 [1] CRAN (R 4.0.2)
gtable 0.3.0 2019-03-25 [1] CRAN (R 4.0.2)
haven 2.3.1 2020-06-01 [1] CRAN (R 4.0.2)
hms 0.5.3 2020-01-08 [1] CRAN (R 4.0.2)
httr 1.4.2 2020-07-20 [1] CRAN (R 4.0.2)
jsonlite * 1.7.1 2020-09-07 [1] CRAN (R 4.0.2)
labeling 0.4.2 2020-10-20 [1] CRAN (R 4.0.2)
lifecycle 0.2.0 2020-03-06 [1] CRAN (R 4.0.2)
lubridate * 1.7.9.9001 2020-11-25 [1] Github (6c535c8)
magrittr 2.0.1 2020-11-17 [1] CRAN (R 4.0.3)
memoise 1.1.0 2017-04-21 [1] CRAN (R 4.0.2)
modelr 0.1.8 2020-05-19 [1] CRAN (R 4.0.2)
munsell 0.5.0 2018-06-12 [1] CRAN (R 4.0.2)
pillar 1.4.7 2020-11-20 [1] CRAN (R 4.0.3)
pkgbuild 1.1.0 2020-07-13 [1] CRAN (R 4.0.2)
pkgconfig 2.0.3 2019-09-22 [1] CRAN (R 4.0.2)
pkgload 1.1.0 2020-05-29 [1] CRAN (R 4.0.2)
prettyunits 1.1.1 2020-01-24 [1] CRAN (R 4.0.2)
processx 3.4.4 2020-09-03 [1] CRAN (R 4.0.2)
ps 1.4.0 2020-10-07 [1] CRAN (R 4.0.2)
purrr * 0.3.4 2020-04-17 [1] CRAN (R 4.0.2)
R.cache 0.14.0 2019-12-06 [1] CRAN (R 4.0.2)
R.methodsS3 1.8.1 2020-08-26 [1] CRAN (R 4.0.2)
R.oo 1.24.0 2020-08-26 [1] CRAN (R 4.0.2)
R.utils 2.10.1 2020-08-26 [1] CRAN (R 4.0.2)
R6 2.5.0 2020-10-28 [1] CRAN (R 4.0.2)
Rcpp 1.0.5 2020-07-06 [1] CRAN (R 4.0.2)
readr * 1.4.0 2020-10-05 [1] CRAN (R 4.0.2)
readxl 1.3.1 2019-03-13 [1] CRAN (R 4.0.2)
rematch2 2.1.2 2020-05-01 [1] CRAN (R 4.0.2)
remotes 2.2.0 2020-07-21 [1] CRAN (R 4.0.2)
reprex 0.3.0 2019-05-16 [1] CRAN (R 4.0.2)
rlang 0.4.8 2020-10-08 [1] CRAN (R 4.0.2)
rprojroot 2.0.2 2020-11-15 [1] CRAN (R 4.0.3)
rsconnect 0.8.16 2019-12-13 [1] CRAN (R 4.0.2)
rstudioapi 0.13 2020-11-12 [1] CRAN (R 4.0.3)
rvest 0.3.6 2020-07-25 [1] CRAN (R 4.0.2)
scales 1.1.1 2020-05-11 [1] CRAN (R 4.0.2)
sessioninfo 1.1.1 2018-11-05 [1] CRAN (R 4.0.2)
stringi 1.5.3 2020-09-09 [1] CRAN (R 4.0.2)
stringr * 1.4.0 2019-02-10 [1] CRAN (R 4.0.2)
styler * 1.3.2 2020-02-23 [1] CRAN (R 4.0.2)
testthat 3.0.0 2020-10-31 [1] CRAN (R 4.0.2)
tibble * 3.0.4 2020-10-12 [1] CRAN (R 4.0.2)
tidyr * 1.1.2 2020-08-27 [1] CRAN (R 4.0.2)
tidyselect 1.1.0 2020-05-11 [1] CRAN (R 4.0.2)
tinytex 0.27 2020-11-01 [1] CRAN (R 4.0.2)
usethis 1.6.3 2020-09-17 [1] CRAN (R 4.0.2)
utf8 1.1.4 2018-05-24 [1] CRAN (R 4.0.2)
vctrs 0.3.5 2020-11-17 [1] CRAN (R 4.0.3)
withr 2.3.0 2020-09-22 [1] CRAN (R 4.0.2)
xfun 0.19 2020-10-30 [1] CRAN (R 4.0.2)
xml2 1.3.2 2020-04-23 [1] CRAN (R 4.0.2)

[1] /Library/Frameworks/R.framework/Versions/4.0/Resources/library

</p>
</details>

rrohwer · 2021-01-11T07:06:13Z

Hi everyone,
Just wanted to let you know that this bug appeared after a mac update for me, not an R update, in case that helps you with your troubleshooting. (Using R 4.0.3) The mac update was a security update that took me to Catalina 10.15.7. I solved it with the Sys.setenv("TZDIR" = "/Library/Frameworks/R.framework/Resources/share/zoneinfo/") command that @gaborcsardi suggested.
Thanks!
Robin

mmuurr · 2021-01-18T06:07:19Z

Since feedback was asked-for, I can report that the most recent commit (aab2e30) does not resolve the issue for me 'out-of-the-box'.
R 4.0.3, Mac OS 10.15.7.

And when I try the explicit TZDIR setting I can resolve it, but it requires knowing the explicit path (which required a manual search through /usr/local). Since I used brew as the installation mechanism (which perhaps was a poor choice?), on my machine this solves the

Sys.setenv("TZDIR" = "/usr/local/Cellar/r/4.0.3_2/lib/R/share/zoneinfo/")

Though I'm not sure how to easily detect that path a priori.

hadley · 2021-01-18T13:36:06Z

@mmuurr what does file.exists(file.path(R.home("share"), "zoneinfo")) return?

andybyte · 2021-02-05T17:14:51Z

Try calling Sys.timezone() before loading the lubridate package. Does that help?
@LeeMendelowitz

This helped me. Just had this issue recently and I don't remember what changed in my system except i did update packages. Not sure if Lubridate was one of them but if I reset the R environment and first run Sys.timezone that seems to do the trick.

cderv · 2021-02-12T17:34:10Z

Per NEWS bullet https://github.com/tidyverse/lubridate/blob/master/NEWS.md#version-1792, It seems that this issue is fixed now right ?

As it is not closed, just want to confirm.

vspinu · 2021-02-13T19:31:00Z

Yes, it should be fixed in devel. Will try to release to CRAN next week.

cderv · 2021-02-13T21:06:36Z

Oh ok, The NEWS item was for 1.7.9.2 so I thought it was already fixed in the CRAN version. So it isn't ?

cderv · 2021-02-15T21:55:45Z

@vspinu I understood what you meant I think.

This has been fully fixed in #936 after first try in 4c8428b it it seems but I don't think the commit for the PR (6c535c8) made the last CRAN release 1.7.9.2 - the date is after the published date on CRAN, and I don't see the change in lubridate:::.onLoad.
Unfortunately, 6c535c8 shows that it is included in the tag of 1.7.9.2 - I was mislead by this I think.

I reverted back the change in distill to use CRAN lubridate and wait for the next version you said you will release soon hopefully.

Thank you.

vspinu · 2021-02-19T08:35:28Z

Sorry. It was a messup with tagging on my side this time :/ I am preparing a CRAN release.

Version 1.7.10 ============== ### NEW FEATURES * `fast_strptime()` and `parse_date_time2()` now accept multiple formats and apply them in turn ### BUG FIXES * [#926](tidyverse/lubridate#926) Fix incorrect division of intervals by months involving leap years * Fix incorrect skipping of digits during parsing of the `%z` format Version 1.7.9.2 =============== ### NEW FEATURES * [#914](tidyverse/lubridate#914) New `rollforward()` function * [#928](tidyverse/lubridate#928) On startup lubridate now resets TZDIR to a proper directory when it is set to non-dir values like "internal" or "macOS" (a change introduced in R4.0.2) * [#630](tidyverse/lubridate#630) New parsing functions `ym()` and `my()` ### BUG FIXES * [#930](tidyverse/lubridate#930) `as.period()` on intervals now returns valid Periods with double fields (not integers) Version 1.7.9 ============= ### NEW FEATURES * [#871](tidyverse/lubridate#893) Add `vctrs` support ### BUG FIXES * [#890](tidyverse/lubridate#890) Correctly compute year in `quarter(..., with_year = TRUE)` * [#893](tidyverse/lubridate#893) Fix incorrect parsing of abbreviated months in locales with trailing dot (regression in v1.7.8) * [#886](tidyverse/lubridate#886) Fix `with_tz()` for POSIXlt objects * [#887](tidyverse/lubridate#887) Error on invalid numeric input to `month()` * [#889](tidyverse/lubridate#889) Export new dmonth function Version 1.7.8 ============= ### NEW FEATURES * (breaking) Year and month durations now assume 365.25 days in a year consistently in conversion and constructors. Particularly `dyears(1) == years(1)` is now `TRUE`. * Format and print methods for 0-length objects are more consistent. * New duration constructor `dmonths()` to complement other duration constructors. * * `duration()` constructor now accepts `months` and `years` arguments. * [#629](tidyverse/lubridate#629) Added `format_ISO8601()` methods. * [#672](tidyverse/lubridate#672) Eliminate all partial argument matches * [#674](tidyverse/lubridate#674) `as_date()` now ignores the `tz` argument * [#675](tidyverse/lubridate#675) `force_tz()`, `with_tz()`, `tz<-` convert dates to date-times * [#681](tidyverse/lubridate#681) New constants `NA_Date_` and `NA_POSIXct_` which parallel built-in primitive constants. * [#681](tidyverse/lubridate#681) New constructors `Date()` and `POSIXct()` which parallel built-in primitive constructors. * [#695](tidyverse/lubridate#695) Durations can now be compared with numeric vectors. * [#707](tidyverse/lubridate#707) Constructors return 0-length inputs when called with no arguments * [#713](tidyverse/lubridate#713) (breaking) `as_datetime()` always returns a `POSIXct()` * [#717](tidyverse/lubridate#717) Common generics are now defined in `generics` dependency package. * [#719](tidyverse/lubridate#719) Negative Durations are now displayed with leading `-`. * [#829](tidyverse/lubridate#829) `%within%` throws more meaningful messages when applied on unsupported classes * [#831](tidyverse/lubridate#831) Changing hour, minute or second of Date object now yields POSIXct. * [#869](tidyverse/lubridate#869) Propagate NAs to all internal components of a Period object ### BUG FIXES * [#682](tidyverse/lubridate#682) Fix quarter extraction with small `fiscal_start`s. * [#703](tidyverse/lubridate#703) `leap_year()` works with objects supported by `year()`. * [#778](tidyverse/lubridate#778) `duration()/period()/make_difftime()` work with repeated units * `c.Period` concatenation doesn't fail with empty components. * Honor `exact = TRUE` argument in `parse_date_time2`, which was so far ignored. Version 1.7.4 ============= ### NEW FEATURES * [#658](tidyverse/lubridate#658) `%within%` now accepts a list of intervals, in which case an instant is checked if it occurs within any of the supplied intervals. ### CHANGES * [#661](tidyverse/lubridate#661) Throw error on invalid multi-unit rounding. * [#633](tidyverse/lubridate#633) `%%` on intervals relies on `%m+` arithmetic and doesn't produce NAs when intermediate computations result in non-existent dates. * `tz()` always returns "UTC" when `tzone` attribute cannot be inferred. ### BUG FIXES * [#664](tidyverse/lubridate#664) Fix lookup of period functions in `as.period` * [#649](tidyverse/lubridate#664) Fix system timezone memoization Version 1.7.3 ============= ### BUG FIXES * [#643](tidyverse/lubridate#643), [#640](tidyverse/lubridate#640), [#645](tidyverse/lubridate#645) Fix faulty caching of system timezone.

msberends · 2022-09-15T12:19:42Z

Sorry to get back to this issue, but we are having this problem with our teams after upgrading to R 4.2.1 on Windows (coming from R 4.1.3, didn't have the warning):

lubridate::now()
#> [1] "2022-09-15 14:17:10 CEST"
#> Warning message:
#> In with_tz(Sys.time(), tzone) : Unrecognized time zone ''
Sys.getlocale()
#> [1] "LC_COLLATE=Dutch_Netherlands.utf8;LC_CTYPE=Dutch_Netherlands.utf8;LC_MONETARY=Dutch_Netherlands.utf8;LC_NUMERIC=C;LC_TIME=Dutch_Netherlands.utf8"
Sys.timezone()
#> [1] "Europe/Berlin"
Sys.getenv("TZDIR")
#> [1] "C:/R/R/R-42~1.1/share/zoneinfo"

^{Created on 2022-09-15 with reprex v2.0.2}

Session info

sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value
#>  version  R version 4.2.1 (2022-06-23 ucrt)
#>  os       Windows 10 x64 (build 19044)
#>  system   x86_64, mingw32
#>  ui       RTerm
#>  language (EN)
#>  collate  Dutch_Netherlands.utf8
#>  ctype    Dutch_Netherlands.utf8
#>  tz       Europe/Berlin
#>  date     2022-09-15
#>  pandoc   2.18 @ C:/R/RStudio/bin/quarto/bin/tools/ (via rmarkdown)
#> 
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package     * version date (UTC) lib source
#>  cli           3.4.0   2022-09-08 [1] CRAN (R 4.1.3)
#>  digest        0.6.29  2021-12-01 [1] CRAN (R 4.1.2)
#>  evaluate      0.16    2022-08-09 [1] CRAN (R 4.1.3)
#>  fansi         1.0.3   2022-03-24 [1] CRAN (R 4.1.3)
#>  fastmap       1.1.0   2021-01-25 [1] CRAN (R 4.0.4)
#>  fs            1.5.2   2021-12-08 [1] CRAN (R 4.1.2)
#>  generics      0.1.3   2022-07-05 [1] CRAN (R 4.1.3)
#>  glue          1.6.2   2022-02-24 [1] CRAN (R 4.1.3)
#>  highr         0.9     2021-04-16 [1] CRAN (R 4.0.5)
#>  htmltools     0.5.3   2022-07-18 [1] CRAN (R 4.1.3)
#>  knitr         1.40    2022-08-24 [1] CRAN (R 4.1.3)
#>  lifecycle     1.0.1   2021-09-24 [1] CRAN (R 4.0.5)
#>  lubridate     1.8.0   2021-10-07 [1] CRAN (R 4.0.5)
#>  magrittr      2.0.3   2022-03-30 [1] CRAN (R 4.1.3)
#>  pillar        1.8.1   2022-08-19 [1] CRAN (R 4.1.3)
#>  pkgconfig     2.0.3   2019-09-22 [1] CRAN (R 4.0.4)
#>  purrr         0.3.4   2020-04-17 [1] CRAN (R 4.0.4)
#>  R.cache       0.16.0  2022-07-21 [1] CRAN (R 4.1.3)
#>  R.methodsS3   1.8.2   2022-06-13 [1] CRAN (R 4.1.3)
#>  R.oo          1.25.0  2022-06-12 [1] CRAN (R 4.1.3)
#>  R.utils       2.12.0  2022-06-28 [1] CRAN (R 4.1.3)
#>  reprex        2.0.2   2022-08-17 [1] CRAN (R 4.1.3)
#>  rlang         1.0.5   2022-08-31 [1] CRAN (R 4.1.3)
#>  rmarkdown     2.16    2022-08-24 [1] CRAN (R 4.1.3)
#>  rstudioapi    0.14    2022-08-22 [1] CRAN (R 4.1.3)
#>  sessioninfo   1.2.2   2021-12-06 [1] CRAN (R 4.1.2)
#>  stringi       1.7.8   2022-07-11 [1] CRAN (R 4.1.3)
#>  stringr       1.4.1   2022-08-20 [1] CRAN (R 4.1.3)
#>  styler        1.7.0   2022-03-13 [1] CRAN (R 4.1.3)
#>  tibble        3.1.8   2022-07-22 [1] CRAN (R 4.1.3)
#>  utf8          1.2.2   2021-07-24 [1] CRAN (R 4.0.5)
#>  vctrs         0.4.1   2022-04-13 [1] CRAN (R 4.1.3)
#>  withr         2.5.0   2022-03-03 [1] CRAN (R 4.1.3)
#>  xfun          0.32    2022-08-10 [1] CRAN (R 4.1.3)
#>  yaml          2.3.5   2022-02-21 [1] CRAN (R 4.1.2)
#> 
#>  [1] C:/R/RPakketten4
#>  [2] C:/R/R/R-4.2.1/library
#> 
#> ──────────────────────────────────────────────────────────────────────────────

Perhaps the same as #945?

hadley · 2022-09-15T12:33:40Z

@msberends given that the previous problem was over a year ago and on mac, it's probably different issue. I'd recommend creating a new issue instead.

msberends · 2022-09-15T12:36:08Z

Makes sense, I'm sorry. Solution found - we had to reinstall lubridate after updating R. So for minor updates (R 4.x to R 4.y) this is apparently required.

jjallaire mentioned this issue Oct 30, 2020

Distill template can't be rendered on Mac rstudio/distill#207

Closed

johnmackintosh mentioned this issue Nov 2, 2020

reported timezone errors on Mac OS johnmackintosh/patientcounter#13

Closed

vspinu closed this as completed in #936 Nov 21, 2020

vspinu pushed a commit that referenced this issue Nov 21, 2020

[#928] Set TZDIR if empty (#936)

6c535c8

* [#928] Call Sys.timezone() onLoad

vspinu reopened this Nov 21, 2020

DavisVaughan mentioned this issue Nov 23, 2020

Runtime support for setting the binary tzdb directory path HowardHinnant/date#626

Open

sebkopf mentioned this issue Dec 31, 2020

JOSS Automated tests isoverse/isoreader#144

Closed

mmuurr mentioned this issue Jan 18, 2021

now() raises warning re: unrecognized time zone #945

Closed

This comment has been minimized.

Sign in to view

joethorley mentioned this issue Feb 4, 2021

wqbc::tidy_ems_data no longer working bcgov/shinyrems#119

Closed

cderv mentioned this issue Feb 12, 2021

Built blog posts display incorrect date (date-1) compared to slug and listing page rstudio/distill#315

Closed

vspinu closed this as completed Feb 13, 2021

cwbeltz mentioned this issue Feb 17, 2021

with_tz in if_else not working #954

Closed

cross85 mentioned this issue Jul 22, 2021

Invalid timezone of the input vector: "GMT" using Linear relations between pollutants function davidcarslaw/openair#263

Closed

BillPetti mentioned this issue Jul 27, 2021

Error Installing BaseballR BillPetti/baseballr#212

Closed

Alternikaner mentioned this issue Jun 1, 2022

Setting timezone parameter in dbConnect throws an error (R 4.2.0 only, Win) r-dbi/odbc#495

Closed

msberends mentioned this issue Sep 15, 2022

Notice user about cache after updating R? #1065

Closed

Timezones not working since the update to R 4.0.3 #928

Timezones not working since the update to R 4.0.3 #928

Comments

rachaelmburke commented Oct 30, 2020 • edited Loading

gaborcsardi commented Oct 30, 2020 • edited Loading

jjallaire commented Oct 31, 2020

jjallaire commented Oct 31, 2020 • edited Loading

jjallaire commented Oct 31, 2020

adamhsparks commented Nov 1, 2020 • edited Loading

gaborcsardi commented Nov 1, 2020

adamhsparks commented Nov 1, 2020

gsiemon commented Nov 1, 2020 • edited Loading

adamhsparks commented Nov 1, 2020

gaborcsardi commented Nov 1, 2020 • edited Loading

gsiemon commented Nov 1, 2020

gaborcsardi commented Nov 1, 2020

adamhsparks commented Nov 1, 2020

gaborcsardi commented Nov 1, 2020 • edited Loading

adamhsparks commented Nov 1, 2020

domq commented Nov 2, 2020 • edited Loading

adamhsparks commented Nov 2, 2020

gaborcsardi commented Nov 2, 2020 • edited Loading

gsiemon commented Nov 2, 2020

adamhsparks commented Nov 2, 2020 • edited Loading

gaborcsardi commented Nov 2, 2020

gsiemon commented Nov 2, 2020 • edited Loading

rachaelmburke commented Nov 2, 2020 • edited Loading

adamhsparks commented Nov 2, 2020 via email

rachaelmburke commented Nov 2, 2020

vspinu commented Nov 2, 2020

vspinu commented Nov 2, 2020

mj-ramirez commented Nov 2, 2020

trifle commented Nov 25, 2020

rrohwer commented Jan 11, 2021

mmuurr commented Jan 18, 2021

hadley commented Jan 18, 2021

This comment has been minimized.

This comment has been minimized.

andybyte commented Feb 5, 2021 • edited Loading

cderv commented Feb 12, 2021

vspinu commented Feb 13, 2021

cderv commented Feb 13, 2021

cderv commented Feb 15, 2021 • edited Loading

vspinu commented Feb 19, 2021

msberends commented Sep 15, 2022 • edited Loading

hadley commented Sep 15, 2022

msberends commented Sep 15, 2022

rachaelmburke commented Oct 30, 2020 •

edited

Loading

gaborcsardi commented Oct 30, 2020 •

edited

Loading

jjallaire commented Oct 31, 2020 •

edited

Loading

adamhsparks commented Nov 1, 2020 •

edited

Loading

gsiemon commented Nov 1, 2020 •

edited

Loading

gaborcsardi commented Nov 1, 2020 •

edited

Loading

gaborcsardi commented Nov 1, 2020 •

edited

Loading

domq commented Nov 2, 2020 •

edited

Loading

gaborcsardi commented Nov 2, 2020 •

edited

Loading

adamhsparks commented Nov 2, 2020 •

edited

Loading

gsiemon commented Nov 2, 2020 •

edited

Loading

rachaelmburke commented Nov 2, 2020 •

edited

Loading

andybyte commented Feb 5, 2021 •

edited

Loading

cderv commented Feb 15, 2021 •

edited

Loading

msberends commented Sep 15, 2022 •

edited

Loading