Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timezones not working since the update to R 4.0.3 #928

Closed
rachaelmburke opened this issue Oct 30, 2020 · 58 comments · Fixed by #936
Closed

Timezones not working since the update to R 4.0.3 #928

rachaelmburke opened this issue Oct 30, 2020 · 58 comments · Fixed by #936

Comments

@rachaelmburke
Copy link

rachaelmburke commented Oct 30, 2020

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
Copy link
Member

gaborcsardi commented Oct 30, 2020

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
Copy link
Contributor

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
Copy link
Contributor

jjallaire commented Oct 31, 2020

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
Copy link
Contributor

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
Copy link

adamhsparks commented Nov 1, 2020

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
Copy link
Member

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

@adamhsparks
Copy link

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

@gsiemon
Copy link

gsiemon commented Nov 1, 2020

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
Copy link

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

@gaborcsardi
Copy link
Member

gaborcsardi commented Nov 1, 2020

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
Copy link

gsiemon commented Nov 1, 2020

@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
Copy link
Member

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
Copy link

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
Copy link
Member

gaborcsardi commented Nov 1, 2020

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
Copy link

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
Copy link

domq commented Nov 2, 2020

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
Copy link

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
Copy link
Member

gaborcsardi commented Nov 2, 2020

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
Copy link

gsiemon commented Nov 2, 2020

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
Copy link

adamhsparks commented Nov 2, 2020

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
Copy link
Member

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

@gsiemon
Copy link

gsiemon commented Nov 2, 2020

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
Copy link
Author

rachaelmburke commented Nov 2, 2020

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
Copy link

adamhsparks commented Nov 2, 2020 via email

@rachaelmburke
Copy link
Author

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

@vspinu
Copy link
Member

vspinu commented Nov 2, 2020

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
Copy link
Member

vspinu commented Nov 2, 2020

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

@mj-ramirez
Copy link

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

@trifle
Copy link

trifle commented Nov 25, 2020

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
Copy link

rrohwer commented Jan 11, 2021

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
Copy link

mmuurr commented Jan 18, 2021

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
Copy link
Member

hadley commented Jan 18, 2021

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

@mmuurr

This comment has been minimized.

@hadley

This comment has been minimized.

@andybyte
Copy link

andybyte commented Feb 5, 2021

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
Copy link
Contributor

cderv commented Feb 12, 2021

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
Copy link
Member

vspinu commented Feb 13, 2021

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

@vspinu vspinu closed this as completed Feb 13, 2021
@cderv
Copy link
Contributor

cderv commented Feb 13, 2021

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
Copy link
Contributor

cderv commented Feb 15, 2021

@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
Copy link
Member

vspinu commented Feb 19, 2021

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

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue May 30, 2021
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
Copy link

msberends commented Sep 15, 2022

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
Copy link
Member

hadley commented Sep 15, 2022

@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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.