David Kepplinger
2020-Oct-31 23:55 UTC
[R] strptime() keeps emitting warnings after establishing a handler with tryCatch()
Dear list members,
I have come about a peculiar behavior in R (4.0.2) which I would
describe as a bug.
On macOS, where `strptime()` raises a warning for invalid timezone
identifiers, the following code will continue to raise the original
warning with every subsequent call to `strptime()`:
```
# attach a handler for warnings for this call only:
tryCatch(strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M',
tz 'Wrong Timezone!'),
warning = function (w) { stop("Error") })
# but every subsequent call will emit the original warning ("unknown
timezone 'Wrong Timezone!'")
strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz =
'Europe/Vienna')
strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz =
'GMT')
```
The output of the code above in R 4.0.2 on macOS is:
> tryCatch(strptime('2020-10-31 18:30', format = '%Y-%m-%d
%H:%M', tz = 'Wrong Timezone!'),
+ warning = function (w) { stop("Error") })
Error in value[[3L]](cond) : Error>
> strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz
= 'Europe/Vienna')
[1] "2020-10-31 18:30:00 CET"
Warning message:
In strptime("2020-10-31 18:30", format = "%Y-%m-%d %H:%M",
tz "Europe/Vienna") :
unknown timezone 'Wrong Timezone!'> strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz
= 'GMT')
[1] "2020-10-31 18:30:00 GMT"
Warning messages:
1: In strptime("2020-10-31 18:30", format = "%Y-%m-%d
%H:%M", tz = "GMT") :
unknown timezone 'Wrong Timezone!'
The corresponding R session info is:
> sessionInfo()
R version 4.0.2 Patched (2020-07-13 r78838)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Catalina 10.15.7
Matrix products: default
BLAS:
/Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib
LAPACK:
/Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.0.2
I get the same odd behavior when attaching calling handlers with
`withCallingHandlers()`.
On RHEL 7 and Cent OS 6, which both don't issue warnings for invalid
timezones, the above code works.
I don't see anything wrong with the code itself, but maybe I am
missing something. Any input would be appreciated.
Best wishes,
David
Rui Barradas
2020-Nov-01 17:51 UTC
[R] strptime() keeps emitting warnings after establishing a handler with tryCatch()
Hello, I cannot reproduce this behavior and, as documented, the posted code doesn't issue warnings due to a wrong timezone but I'm running sessionInfo() R version 4.0.3 (2020-10-10) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 20.04.1 LTS Matrix products: default BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0 LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0 locale: [1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C [3] LC_TIME=pt_PT.UTF-8 LC_COLLATE=pt_PT.UTF-8 [5] LC_MONETARY=pt_PT.UTF-8 LC_MESSAGES=pt_PT.UTF-8 [7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.0.3 Hope this helps, Rui Barradas ?s 23:55 de 31/10/20, David Kepplinger escreveu:> Dear list members, > > I have come about a peculiar behavior in R (4.0.2) which I would > describe as a bug. > On macOS, where `strptime()` raises a warning for invalid timezone > identifiers, the following code will continue to raise the original > warning with every subsequent call to `strptime()`: > > ``` > # attach a handler for warnings for this call only: > tryCatch(strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz > 'Wrong Timezone!'), > warning = function (w) { stop("Error") }) > # but every subsequent call will emit the original warning ("unknown > timezone 'Wrong Timezone!'") > strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz = 'Europe/Vienna') > strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz = 'GMT') > ``` > > The output of the code above in R 4.0.2 on macOS is: > >> tryCatch(strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz = 'Wrong Timezone!'), > + warning = function (w) { stop("Error") }) > Error in value[[3L]](cond) : Error >> >> strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz = 'Europe/Vienna') > [1] "2020-10-31 18:30:00 CET" > Warning message: > In strptime("2020-10-31 18:30", format = "%Y-%m-%d %H:%M", tz > "Europe/Vienna") : > unknown timezone 'Wrong Timezone!' >> strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz = 'GMT') > [1] "2020-10-31 18:30:00 GMT" > Warning messages: > 1: In strptime("2020-10-31 18:30", format = "%Y-%m-%d %H:%M", tz = "GMT") : > unknown timezone 'Wrong Timezone!' > > The corresponding R session info is: > >> sessionInfo() > R version 4.0.2 Patched (2020-07-13 r78838) > Platform: x86_64-apple-darwin17.0 (64-bit) > Running under: macOS Catalina 10.15.7 > > Matrix products: default > BLAS: /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib > LAPACK: /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib > > locale: > [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > loaded via a namespace (and not attached): > [1] compiler_4.0.2 > > > I get the same odd behavior when attaching calling handlers with > `withCallingHandlers()`. > On RHEL 7 and Cent OS 6, which both don't issue warnings for invalid > timezones, the above code works. > > I don't see anything wrong with the code itself, but maybe I am > missing something. Any input would be appreciated. > > Best wishes, > David > > ______________________________________________ > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. >
David Kepplinger
2020-Nov-01 18:34 UTC
[R] strptime() keeps emitting warnings after establishing a handler with tryCatch()
Thanks, Rui, for checking on your end. I don't think any Linux-based system is affected, as they silently ignore invalid timezone identifiers (at least the versions I know of). I now also had a chance to test on Windows 10 and get the same errors as under macOS. The session info for this test is> sessionInfo()R version 4.0.2 (2020-06-22) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 19041) Matrix products: default locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_4.0.2 I also tested a bit more and it seems that attaching handlers really messes up `strptime()`. For example, `strptime()` stops to emit any warning for invalid timezone identifiers:> tryCatch(strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz = 'Wrong Timezone!'),+ warning = function (w) { stop("Error") }) Error in value[[3L]](cond) : Error> # The following calls with a wrong timezone identifier don't emit any warnings anymore?! > strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz = 'Wrong Timezone!')[1] "2020-10-31 18:30:00" But a subsequent call to `strptime()` with a valid timezone identifier does emit the original warning (continuing the R session from above):> strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz = 'GMT')[1] "2020-10-31 18:30:00 GMT" Warning messages: 1: In strptime("2020-10-31 18:30", format = "%Y-%m-%d %H:%M", tz = "GMT") : unknown timezone 'Wrong Timezone!' And the next call with an incorrect tz identifier, doesn't emit a warning, but uses the timezone from the previous call (continuing the R session as above):> strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz = 'Wrong Timezone!')[1] "2020-10-31 18:30:00 GMT" Best wishes, David On Sun, Nov 1, 2020 at 9:51 AM Rui Barradas <ruipbarradas at sapo.pt> wrote:> > Hello, > > I cannot reproduce this behavior and, as documented, the posted code > doesn't issue warnings due to a wrong timezone but I'm running > > > sessionInfo() > R version 4.0.3 (2020-10-10) > Platform: x86_64-pc-linux-gnu (64-bit) > Running under: Ubuntu 20.04.1 LTS > > Matrix products: default > BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0 > LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0 > > locale: > [1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C > [3] LC_TIME=pt_PT.UTF-8 LC_COLLATE=pt_PT.UTF-8 > [5] LC_MONETARY=pt_PT.UTF-8 LC_MESSAGES=pt_PT.UTF-8 > [7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C > [9] LC_ADDRESS=C LC_TELEPHONE=C > [11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > loaded via a namespace (and not attached): > [1] compiler_4.0.3 > > > Hope this helps, > > Rui Barradas > > ?s 23:55 de 31/10/20, David Kepplinger escreveu: > > Dear list members, > > > > I have come about a peculiar behavior in R (4.0.2) which I would > > describe as a bug. > > On macOS, where `strptime()` raises a warning for invalid timezone > > identifiers, the following code will continue to raise the original > > warning with every subsequent call to `strptime()`: > > > > ``` > > # attach a handler for warnings for this call only: > > tryCatch(strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz > > 'Wrong Timezone!'), > > warning = function (w) { stop("Error") }) > > # but every subsequent call will emit the original warning ("unknown > > timezone 'Wrong Timezone!'") > > strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz = 'Europe/Vienna') > > strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz = 'GMT') > > ``` > > > > The output of the code above in R 4.0.2 on macOS is: > > > >> tryCatch(strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz = 'Wrong Timezone!'), > > + warning = function (w) { stop("Error") }) > > Error in value[[3L]](cond) : Error > >> > >> strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz = 'Europe/Vienna') > > [1] "2020-10-31 18:30:00 CET" > > Warning message: > > In strptime("2020-10-31 18:30", format = "%Y-%m-%d %H:%M", tz > > "Europe/Vienna") : > > unknown timezone 'Wrong Timezone!' > >> strptime('2020-10-31 18:30', format = '%Y-%m-%d %H:%M', tz = 'GMT') > > [1] "2020-10-31 18:30:00 GMT" > > Warning messages: > > 1: In strptime("2020-10-31 18:30", format = "%Y-%m-%d %H:%M", tz = "GMT") : > > unknown timezone 'Wrong Timezone!' > > > > The corresponding R session info is: > > > >> sessionInfo() > > R version 4.0.2 Patched (2020-07-13 r78838) > > Platform: x86_64-apple-darwin17.0 (64-bit) > > Running under: macOS Catalina 10.15.7 > > > > Matrix products: default > > BLAS: /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRblas.dylib > > LAPACK: /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib > > > > locale: > > [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 > > > > attached base packages: > > [1] stats graphics grDevices utils datasets methods base > > > > loaded via a namespace (and not attached): > > [1] compiler_4.0.2 > > > > > > I get the same odd behavior when attaching calling handlers with > > `withCallingHandlers()`. > > On RHEL 7 and Cent OS 6, which both don't issue warnings for invalid > > timezones, the above code works. > > > > I don't see anything wrong with the code itself, but maybe I am > > missing something. Any input would be appreciated. > > > > Best wishes, > > David > > > > ______________________________________________ > > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see > > https://stat.ethz.ch/mailman/listinfo/r-help > > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > > and provide commented, minimal, self-contained, reproducible code. > >