Timezones not working since the update to R 4.0.3

[rachaelmburke]

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 (?)

[gaborcsardi]

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]

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]

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]

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]

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]

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

[adamhsparks]

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

[gsiemon]

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]

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

[gaborcsardi]

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]

@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]

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]

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]

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.