Wrong time zone is used in the container

[fabm3n]

Background (please complete the following information):

• Panel or Daemon: Dameon
• Version of Panel/Daemon: beta v5
• Server's OS: Ubuntu 20.04
• uname -a: Linux leo 5.4.0-31-generic Initial translation to pt_BR #35-Ubuntu SMP Thu May 7 20:20:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
• docker info:

Client:
 Debug Mode: false

Server:
 Containers: 1
  Running: 1
  Paused: 0
  Stopped: 0
 Images: 14
 Server Version: 19.03.9
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 init version: fec3683
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.4.0-31-generic
 Operating System: Ubuntu 20.04 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 15.27GiB
 Name: leo
 ID: UKQH:AQFM:AKU2:AAF5:QUII:BPPD:REUL:DPSO:CIIM:VR2B:MI5O:XKBY
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No swap limit support

Describe the bug
The time zone used in the docker container is wrong. It's always UTC.
In the Daemon config the tim zon path is /etc/timezone and in this file is "Europe/Berlin" written.
timedatectl also displays the correct time zone (Europe/Berlin).

To Reproduce
Steps to reproduce the behavior:

1. Install a Server (Example Minecraft Vanilla)
2. Check the times in the console. These are UTC.

Expected behavior
The time should be like the timezone set in /etc/timezone

[matthewpi]

So after reading into Docker and timezones I decided that it would be best to experiment outside of Pterodactyl and see how raw centos and debian containers behave with different environment variables and mounts.

CentOS 8 - America/Edmonton timezone on host, no TZ variable in container:
https://ok.dnf.wtf/ERGbLv8ybRKKn.png

CentOS 8 - America/Edmonton timezone on host, America/Edmonton TZ variable in container:
https://ok.dnf.wtf/K1T8yC5YGUiOI.png

CentOS 8 - America/Edmonton timezone on host, no TZ variable in container, /etc/timezone:/etc/timezone:ro mount:
https://ok.dnf.wtf/ZmGxfJa0wSRb0.png

CentOS 8 - America/Edmonton timezone on host, no TZ variable in container, /etc/localtime:/etc/localtime:ro mount:
https://ok.dnf.wtf/NOaOiucTFDjr9.png

--

Debian (buster-slim) - America/Edmonton timezone on host, no TZ variable in container:
https://ok.dnf.wtf/wHauLeLOWMOkc.png

Debian (buster-slim) - America/Edmonton timezone on host, America/Edmonton TZ variable in container:
https://ok.dnf.wtf/VFrqqKVEA5UEE.png

Debian (buster-slim) - America/Edmonton timezone on host, no TZ variable in container, /etc/timezone:/etc/timezone:ro mount:
Failed because debian already has a /etc/timezone file.
https://ok.dnf.wtf/E0DBsImp8LMN9.png

Debian (buster-slim) - America/Edmonton timezone on host, no TZ variable in container, /etc/localtime:/etc/localtime:ro mount:
https://ok.dnf.wtf/gv360IB85cJLY.png

So it seems that the best combination would be a TZ= and a /etc/localtime mount. In CentOS, /etc/timezone is a folder that has no content by default (this was on the host with a fresh minimal install). While the date command seems to respect the TZ environment variable, it doesn't mean applications that get time will use it. On debian, /etc/timezone cannot be mounted because it is a file that already exist, a workaround would be to run echo $TZ > /etc/timezone in the image's entrypoint.sh to update the file (if the image is debian based, not sure about alpine).

[fabm3n]

Issue still exists, like in #2239

[kFxDaKing]

same problem Europe/Prague - 2 hours

[johncsuti]

Same issue is this going to be looked into or should a new issue be opened for it to be seen?

[DaneEveritt]

No.

#2239 (comment)