tidyverse / lubridate

Make working with dates in R just that little bit easier
https://lubridate.tidyverse.org
GNU General Public License v3.0
728 stars 207 forks source link

Timezones not working since the update to R 4.0.3 #928

Closed rachaelmburke closed 3 years ago

rachaelmburke commented 3 years ago

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

cderv commented 3 years ago

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 commented 3 years ago

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

cderv commented 3 years ago

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 commented 3 years ago

@vspinu I understood what you meant I think.

This has been fully fixed in https://github.com/tidyverse/lubridate/pull/936 after first try in 4c8428b7b3bd30c8789340381ebd9f455308dc27 it it seems but I don't think the commit for the PR (6c535c82ed7f263ce5daceba9c87827400d4423e) 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, 6c535c82ed7f263ce5daceba9c87827400d4423e 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 commented 3 years ago

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

msberends commented 2 years ago

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 ``` r 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 commented 2 years ago

@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 commented 2 years ago

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.