Hi there,
I tried some the suggestions in the internet like, e.g, Change host date/time (RTC) from inside docker container and https://stackoverflow.com/questions/24551592/how-to-make-sure-dockers-time-syncs-with-that-of-the-host , but the “date” command continues to show different outputs when run from the docker container and the host system. Any help is welcome.
Thanks in advance
Hi, I’m the Toradex AI Assistant.
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
I’d be glad to help! To provide the most accurate guidance, could you let me know:
You can get this information quickly by running the tdx-info command on your device. More details are available at https://developer.toradex.com/software/development-resources/tdx-info/.
While I gather your specific setup details, here are some general considerations for time synchronization between Docker containers and the host on Torizon:
Container Time Isolation:
By default, Docker containers share the host’s kernel but may have isolated views of certain system resources. Time synchronization issues can occur when:
/etc/localtime or /etc/timezoneCommon Solutions:
Mount timezone information by adding volume mounts when running your container:
-v /etc/localtime:/etc/localtime:ro
-v /etc/timezone:/etc/timezone:ro
Verify time source access - ensure your container can access the system clock
Check for timezone mismatches between the host and container environments
Once you provide your OS version and hardware details, I can give you more specific instructions tailored to your Torizon setup.
Best regards,
Toradex AI Assistant.
Did you like my answer? 
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Greetings @vic,
How exactly are you running your container in this case?
I just did a test and it seems to work fine with the following:
$ docker run -it -d --rm --name coj -v /etc/localtime:/etc/localtime:ro debian /bin/bash
# On host
$ date
Fri Jul 10 10:57:52 AM PDT 2026
$ docker exec -it coj /bin/bash
# In container
$ date
Fri Jul 10 10:57:59 PDT 2026
As you can see I just had to bind-mount /etc/localtime from the host into the container. Once I did that the time output of date in the container matches the host.
Best Regards,
Jeremias
Hi @jeremias.tx ,
The problem arises when I use NTP to set date and time in the host by running “timedatectl -set-ntp true” and “timedatectl -set-timezone timezone”. Then, the date and time are updated in the host, but not in the container, maybe because the container continues attached to the UTC time? See this output:
torizon@colibri-imx8x-06996015:~$ date
Mon Jul 13 06:40:49 BST 2026
torizon@colibri-imx8x-06996015:~$ docker exec torizon-debug-1 date
Mon Jul 13 07:40:59 CEST 2026torizon@colibri-imx8x-06996015:~$ file /etc/localtime
/etc/localtime: symbolic link to ../usr/share/zoneinfo/Europe/London
torizon@colibri-imx8x-06996015:~$ docker exec torizon-debug-1 file /etc/localtime
/etc/localtime: symbolic link to /usr/share/zoneinfo/Etc/UTCtorizon@colibri-imx8x-06996015:~$ cat /etc/timezone
Universal
torizon@colibri-imx8x-06996015:~$ docker exec torizon-debug-1 cat /etc/timezone
Universal
Thanks in advance.
V
I see. The issue here is that when you bind-mount /etc/localtime directly into the container it follows the symlink at the time of container creation. Which leads to /etc/localtime in the container not being a symlink like it is on the host. This means if the symlink on the host were to change, which is what timedatectl set-timezone timezone does, then this doesn’t update /etc/localtime in the container.
What you can do is instead bind-mount the parent directory /etc in this case. If you do that then changes under /etc on the host (like symlink changes), should be reflected in the container.
I did a quick test and it seems to work:
torizon@verdin-imx8mp-06849059:~$ docker run -it -d --rm --name coj -v /etc/:/etc/:ro debian /bin/bash
torizon@verdin-imx8mp-06849059:~$ date
Mon Jul 13 16:52:48 UTC 2026
torizon@verdin-imx8mp-06849059:~$ docker exec -it coj date
Mon Jul 13 16:52:51 UTC 2026
torizon@verdin-imx8mp-06849059:~$ sudo timedatectl set-timezone America/Los_Angeles
torizon@verdin-imx8mp-06849059:~$ date
Mon Jul 13 09:53:10 PDT 2026
torizon@verdin-imx8mp-06849059:~$ docker exec -it coj date
Mon Jul 13 09:53:13 PDT 2026
As you can see, by bind-mounting all of /etc, changing timezone on the host gets reflected properly into the container as well.
Best Regards,
Jeremias
Hi @jeremias.tx ,
Thanks for your input. If I bind “/etc/:/etc/:ro” to the volumes section at my docker-compose file, I get the following error in VSCode:
- Executing task: xonsh /home/repo/normoplatform_GUI/.conf/service-check.xsh ssh ‘XXX’ 2231 torizon 192.168.1.129 ‘echo ssh-ok’
Exception occurred: Command ‘[‘sshpass’, ‘-p’, ‘t..’, ‘ssh’, ‘-p’, ‘2231’, ‘-o’, ‘UserKnownHostsFile=/dev/null’, ‘-o’, ‘StrictHostKeyChecking=no’, ‘-o’, ‘PubkeyAuthentication=no’, ‘torizon@192.168.1.129’, ‘echo ssh-ok’]’ returned non-zero exit status 255.
Attempt 1/15: waiting for ssh…
After 15 attempts, the scripts stops. This is my complete volumes section:
volumes: #- "/etc/localtime:/etc/localtime:ro" #- "/etc/timezone:/etc/timezone:ro" - "/etc/:/etc/:ro" - "/etc/requests:/requests" - type: bind source: /tmp target: /tmp - type: bind source: /dev target: /dev - type: bind source: /etc/GUI_ArchiveRoot target: /home/torizon/GUI_ArchiveRoot - type: bind source: /media target: /media bind: propagation: rshared - type: bind source: /run/dbus/system_bus_socket target: /run/dbus/system_bus_socket
Thanks in advance.
V
I assume this is in the debug version of your container?
In the debug container some data gets written to /etc so that VSCode can connect via SSH during the debug process. But if you bind-mount the host /etc this would overwrite the original /etc in the container. Which is why you’re seeing an issue with the SSH process failing in VSCode.
Not sure there’s an elegant way around this in the debug container that doesn’t break the debug functionality. In the release version of the container this wouldn’t be a problem I imagine since there’s no debug process of course.
This might be something you can only realistically test in the release version of the container.
Best Regards,
Jeremias
Yes, I tried in the debug container. I will try the release version when I have time.
In the meantime, I found out that calling setenv(“TZ”, TimeZoneID, 1) is a feasible workaround to get timezone updated in my app (not in the container).
Thanks for your support.
Glad we were able to help.
Best Regards,
Jeremias