Skip to content

Timezone conversion on Ubuntu 20.04

5 messages · David Winsemius, Dirk Eddelbuettel, Johannes Ranke +1 more

Original
Jeroen Ooms
# 
Hi all,

I am testing R 4.0 and ran into an issue with timezones on Ubuntu
Focal: converting a timestamp to another timezone results in NA:

  as.POSIXct(as.POSIXlt(Sys.time(), tz = "CET"), tz = "EST")

This only happens on Ubuntu Focal, it seems to work fine on Ubuntu
Bionic. I am the standard ubuntu docker image icw/ r-base from Dirk's
ppa:edd/r-4.0 on both systems.

Am I missing a system dependency for tzone data?

Jeroen
David Winsemius
#
On 4/24/20 4:02 PM, Jeroen Ooms wrote:
I don't really know but I do know that "EST" is often not a specific 
valid value. It is used by both the USA and Australia. More valid 
designation would probably be "America/New_York"

The vector of valid names is returned by:

OlsonNames(tzdir = NULL)
Dirk Eddelbuettel
#
On 24 April 2020 at 17:46, David Winsemius wrote:
| On 4/24/20 4:02 PM, Jeroen Ooms wrote:
| > I am testing R 4.0 and ran into an issue with timezones on Ubuntu
| > Focal: converting a timestamp to another timezone results in NA:
| >
| >    as.POSIXct(as.POSIXlt(Sys.time(), tz = "CET"), tz = "EST")
| >
| > This only happens on Ubuntu Focal, it seems to work fine on Ubuntu
| > Bionic. I am the standard ubuntu docker image icw/ r-base from Dirk's
| > ppa:edd/r-4.0 on both systems.
| >
| > Am I missing a system dependency for tzone data?

Maybe. What does `dpkg -s tzdata` say? Installed?  Or not?

The base images are pretty narrow and may simply not have it installed.
 
| I don't really know but I do know that "EST" is often not a specific 
| valid value. It is used by both the USA and Australia. More valid 
| designation would probably be "America/New_York"
| 
| The vector of valid names is returned by:
| 
| OlsonNames(tzdir = NULL)

Excellent point by David.

Also, there are _two_ issues here:

 - Does the machine itself have timezone information, ie can you access with
   anything other than R?  You hinted at that with question about 'tzdata'

 - If it does, did R regress?  At some point years ago R was less clever
   about finding tz info when the /etc/ softlink was not set. I coded up one
   smarter heuristic in CRAN package 'gettz'; later R itself carried some of
   that same logic. This obviously needs the system info from the previous
   question.

Dirk
Johannes Ranke
# 
Am Samstag, 25. April 2020, 01:02:38 CEST schrieb Jeroen Ooms:
works fine using the backported R 4.0.0 on Debian buster:

R> as.POSIXct(as.POSIXlt(Sys.time(), tz = "CET"), tz = "EST")
[1] "2020-04-25 10:05:29 EST"

Johannes
1 day later
Jeroen Ooms
#
On Sat, Apr 25, 2020 at 10:41 AM Johannes Ranke <johannes.ranke at jrwb.de> wrote:
Perhaps the root cause of the change in behavior is that on the
focal/bullseye docker images, /usr/bin/timedatectl exists, but it does
not work:

   root at focal:/# timedatectl
   System has not been booted with systemd as init system (PID 1).
Can't operate.
   Failed to create bus connection: Host is down

R assumes that if it timedatectl exists, it can be used. On the docker
image of bionic and buster, timedatectl simply is not installed so R
does not call it.

The consequence though, is very subtle changes in behavior of time
conversion edge cases that I cannot explain. For example we get
differences between "UTC" and "Etc/UTC":
[1] "Etc/UTC"
# System has not been booted with systemd as init system (PID 1). Can't operate.
# Failed to create bus connection: Host is down
Warning message:
In system("timedatectl", intern = TRUE) :
  running command 'timedatectl' had status 1

as.POSIXct(strptime("24.04.2020 01:00", format = "%d.%m.%Y %H:%M", tz
= "CET"), tz = "")
[1] NA

as.POSIXct(strptime("24.04.2020 01:00", format = "%d.%m.%Y %H:%M", tz
= "CEST"), tz = "")
[1] "2020-04-24 01:00:00 UTC"
[1] NA
[1] "2020-04-24 01:00:00 UTC"