Lubridate issue when label = TRUE (error in factor)

[Thalie]

Hello,

I have just got a new laptop and as I was testing my R codes in a new RStudio/R environment I encountered an issue with lubridate labels that I have not been able to figure out yet. I suspect some package incompatibility, but any hint / way forward to investigate and solve the issue would be helpful. Thank you!

RStudio 2023.09.1 Build 494

sessionInfo()

R version 4.3.2 (2023-10-31 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19045)
other attached packages:
[1] lubridate_1.9.3

I have tested the following examples with the month() function, reproduced from the lubridate documentation, the first example is working seamlessly, but as soon as I introduce labels I get a factor error label - I get a similar error with other lubridatefunctions (e.g. wday())

month(ymd(080101))

[1] 1

label
logical. TRUE will display the month as a character string such as "January." FALSE will display the month as a number.

month(ymd(080101), label = TRUE)

Error in factor(x, ..., ordered = TRUE) :
invalid 'labels'; length 10 should be 1 or 12

[jrkrideau]

Your examples are working fine for me.

Maybe try a reboot or a re-installation of {lubridate}?

sessionInfo()
R version 4.3.2 (2023-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 22.04.3 LTS

Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.10.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.10.0

locale:
[1] LC_CTYPE=en_CA.UTF-8 LC_NUMERIC=C LC_TIME=en_CA.UTF-8
[4] LC_COLLATE=en_CA.UTF-8 LC_MONETARY=en_CA.UTF-8 LC_MESSAGES=en_CA.UTF-8
[7] LC_PAPER=en_CA.UTF-8 LC_NAME=C LC_ADDRESS=C
[10] LC_TELEPHONE=C LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C

time zone: America/New_York
tzcode source: system (glibc)

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

other attached packages:
[1] lubridate_1.9.3 forcats_1.0.0 stringr_1.5.0 dplyr_1.1.3 purrr_1.0.2
[6] readr_2.1.4 tidyr_1.3.0 tibble_3.2.1 ggplot2_3.4.4 tidyverse_2.0.0
[11] data.table_1.14.8

loaded via a namespace (and not attached):
[1] vctrs_0.6.4 pryr_0.1.6 cli_3.6.1 rlang_1.1.1 stringi_1.7.12
[6] generics_0.1.3 glue_1.6.2 colorspace_2.1-0 pak_0.6.0 hms_1.1.3
[11] scales_1.2.1 fansi_1.0.5 grid_4.3.2 munsell_0.5.0 tzdb_0.4.0
[16] lifecycle_1.0.3 compiler_4.3.2 lobstr_1.1.2 codetools_0.2-19 timechange_0.2.0
[21] Rcpp_1.0.11 pkgconfig_2.0.3 rstudioapi_0.15.0 R6_2.5.1 tidyselect_1.2.0
[26] utf8_1.2.4 pillar_1.9.0 magrittr_2.0.3 withr_2.5.2 tools_4.3.2
[31] gtable_0.3.4

[nirgrahamuk]

after encountering your error,
what do you see when you run the month name.
do you see something like

> month
function (x, label = FALSE, abbr = TRUE, locale = Sys.getlocale("LC_TIME")) 
{
    UseMethod("month")
}
<bytecode: 0x000001f7bfb27770>
<environment: namespace:lubridate>

[Thalie]

Thank you both for your inputs. I rebooted my laptop and the functions this time indeed worked smoothly in the console... but not in my script. I have checked that before getting the error in the script I indeed get the expected output

lubridate::month

function (x, label = FALSE, abbr = TRUE, locale = Sys.getlocale("LC_TIME"))
{
UseMethod("month")
}
<bytecode: 0x0000014b9c717630>
<environment: namespace:lubridate>

This led me to identify that lubridate functions actually work correctly when LC_TIME is set to English but is failing when set to French, which is the locale setting I am using in my script and the setting I had used in my previous tests in the console (but had not exported with the session information )

Interestingly, it seems that it may be linked to my default configuration being in Swiss German, which possibly creates some incompatibilities with French but not with English.

Sys.getlocale()

[1] "LC_COLLATE=German_Switzerland.utf8;LC_CTYPE=German_Switzerland.utf8;LC_MONETARY=German_Switzerland.utf8;LC_NUMERIC=C;LC_TIME=German_Switzerland.utf8"

My guess is that I now probably have to set these locale variables to English in my R profile to solve the issue (which was probably the case in my old configuration), but would be interested in better understanding how these locale variables work exactly

[nirgrahamuk]

If you find that lubridate is an issue on a particular locale that is reproducible, it may be useful to raise it as an issue on the lubridate github issues page so that it could be addressed to help you and others

Good that you found a solution for yourself, well done

[Thalie]

Noted, I was a bit too tired yesterday to be as systematic as I wanted, but will investigate more to be sure that reproducible and fully documented and open an issue on the lubridate GitHub

Thanks again for the help, this has been very helpful for me to eliminate possible issues and focus my investigations