apps executed inside singularity container doesn't use the same timezone as the host

[pescobar]

while testing singularity I have noticed that a tool executed inside a container is not using the same timezone as the host.

This is the date in the host machine where singularity is executed

[escobar@login20 benchmark-pipeline1]$ timedatectl 
      Local time: Mon 2017-05-22 17:46:27 CEST
  Universal time: Mon 2017-05-22 15:46:27 UTC
        RTC time: Mon 2017-05-22 15:46:27
       Time zone: Europe/Zurich (CEST, +0200)
     NTP enabled: yes
NTP synchronized: yes

And these are the generated logs from the tool executed inside the container:

May 22 15:31:54 ..... started STAR run
May 22 15:31:54 ... starting to generate Genome files
May 22 15:32:53 ... starting to sort Suffix Array. This may take a long time...
May 22 15:33:07 ... sorting Suffix Array chunks and saving them to disk...
May 22 15:46:58 ... loading chunks from disk, packing SA...
May 22 15:47:56 ... finished generating suffix array
May 22 15:47:56 ... generating Suffix Array index

It seems inside the container is using UTC instead of the host timezone. Is there any solution so the container uses the host's timezone?

[gmkurtzer]

It seems if I bind the file /etc/localtime into the container at runtime (singularity shell -B /etc/localtime ...) Things seem to work fine. Can you verify?

[pescobar]

Hi @gmkurtzer

This doesn't solve the problem for me.

[root@login20 pipeline2]# ls -la /etc/localtime 
lrwxrwxrwx. 1 root root 35 Mar 13 17:10 /etc/localtime -> ../usr/share/zoneinfo/Europe/Zurich

[root@login20 pipeline2]# date
Tue May 23 12:02:09 CEST 2017

[root@login20 pipeline2]# singularity shell -B /etc/localtime pipeline2.img
Singularity: Invoking an interactive shell within container...

Singularity.pipeline2.img> date
Tue May 23 10:02:22 CEST 2017

Singularity.pipeline2.img> ls -la /etc/localtime 
lrwxrwxrwx 1 root root 25 Dec 14 14:59 /etc/localtime -> ../usr/share/zoneinfo/UTC

I did the tests with the latest release singularity-2.2.1 installed in centos7.3 host. The tests are executed as root

[gmkurtzer]

Hi @pescobar What is the output of:

$ sudo hwclock
$ sudo hwclock --localtime
$ date

Return on your host system?

[pescobar]

[root@login20 pipeline2]# hwclock
Wed 24 May 2017 09:36:41 AM CEST  -0.457992 seconds

[root@login20 pipeline2]# hwclock --localtime
Wed 24 May 2017 07:36:53 AM CEST  -0.391080 seconds

[root@login20 pipeline2]# date
Wed May 24 09:37:06 CEST 2017

[gmkurtzer]

@pescobar I am just curious, are you running the same distribution within the container as on the host? If not, what happens if you do? Is it the same?

Thanks!

[pescobar]

Yes. I am running centos 7.3 in both the host and the container. Does this makes any difference?

[gmkurtzer]

It really shouldn't but I thought maybe if the timezone files were of different formats that might explain it... But alas, nope. I'm confused and I can't seem to replicate.

[vsoch]

Timezone? Time? My computer thinks it's 3 hours in the future in one browser but not the other, and I'm ok with this. ;) Non productive comment, yes, but couldn't help myself 😉

[gmkurtzer]

Haha. You know, if the earth were flat we wouldn't have these problems! Oh wait, maybe we would (http://theflatearthsociety.org/home/).... But I too digress.

[moskalenko]

I was testing this same issue a few days ago after posting about it on slack and at that time 2.9.99 didn't have this problem. I just re-checked with the newly released singularity-2.3.0 and the 2.2 problem is still absent.

[ArangoGutierrez]

@pescobar does the bug persist on your host?

[roxma]

I tried setting environment TZ=$(cat /etc/timezone) before running the image. It works well.

$ ./foo.simg date
Wed May 30 01:29:26 UTC 2018
$ TZ=$(cat /etc/timezone) ./foo.simg date
Wed May 30 09:29:34 HKT 2018
$ date
Wed May 30 09:32:02 HKT 2018

[jscook2345]

This looks to be fixed to me. I could not reproduce the problem using various attempts. Please comment here if you still have problems @pescobar . Thanks!