Timezone discrepancy between container and host about diun

[crazy-max]

Thanks for reporting, I'm taking a look.

[crazy-max]

I'm able to repro:

t := time.Now()
zone, offset := t.Zone()
fmt.Println("TZ", os.Getenv("TZ"))
fmt.Println("zone", zone)
fmt.Println("offset", offset)

diun  | TZ Europe/Paris
diun  | zone UTC
diun  | offset 0

Might be a change since Go 1.21.

Doesn't look like tzdata was ever installed... 🤔

@Guiorgy This is not needed, we already embed tzdata in the app:

diun/cmd/main.go

Line 8 in 7567529

_ "time/tzdata"

[Fayyaadh]

I think I might be having the same issue.

I updated the diun container to the latest image and where I used to have it check everyday at 2pm (UTC+2), today it decided to check at 4pm.

root@portainer:~# date
Mon Mar 25 16:27:03 SAST 2024
root@portainer:~# docker exec diun date
Mon Mar 25 14:27:34 UTC 2024

[Guiorgy]

This is a general problem with containers based on Alpine Linux. By default the image doesn't come with the tzdata package preinstalled, which is necessary for time zones to work properly. You can try this (replace Diun with the container name/id if different):

# docker exec -it Diun exec ash
# date
Mon Mar 25 **:**:** UTC 2024
# apk add --no-cache tzdata
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/x86_64/APKINDEX.tar.gz
(1/1) Installing tzdata (2024a-r0)
OK: 12 MiB in 18 packages
# date
Mon Mar 25 **:**:** +** 2024

You can read this issue if you want to know why the package is not included with the image.

Unless Diun requires time zones to work properly, they are an optional, so the user should install the package if desired.

[ch4ox]

I had the same problem since the v4.27.0 update -> timezone Europe/Berlin [UTC+1] for me.

What helped for me:

• removing the TZ environment variable (<- this is important)
• using "/etc/localtime:/etc/localtime:ro" as a volume mount

Hope this still works after daylight saving next weekend.

[Fayyaadh]

Everything was fine prior to updating diun a few days ago to the latest image.

[Guiorgy]

Everything was fine prior to updating diun a few days ago to the latest image.

If that's the case, first of all, didn't notice, and secondly, the only significant differences in the dockerfile I can see are version bumps for golang (1.20 -> 1.21) and tonistiigi/xx (1.2.1 -> 1.3.0), of which the later had substantially more refactoring done, but I didn't see tzdata referenced directly, nor anything that depends on it directly, so perhaps it was a transient package?

[Fayyaadh]

Everything was fine prior to updating diun a few days ago to the latest image.

If that's the case, first of all, didn't notice, and secondly, the only significant differences in the dockerfile I can see are version bumps for golang (1.20 -> 1.21) and tonistiigi/xx (1.2.1 -> 1.3.0), of which the later had substantially more refactoring done, but I didn't see tzdata referenced directly, nor anything that depends on it directly, so perhaps it was a transient package?

No idea.

But no config has changed on my side at all, and this started happening after updating to the latest release. I also had a look at the release notes and nothing obvious stood out.

I guess when the developer sees this thread, he'll look into it.

Apart from that, I guess I can try the suggestion above to get rid of the environment variable and get local time from the host. Or the more hacky way of adjusting my cron schedule so that's it's UTC.

[Jefe2]

I’m also having the same problem, ever since updating to v4.27.0 a couple days ago.

[Guiorgy]

# docker run -it --rm --platform linux/amd64 --entrypoint ash crazymax/diun:4.26
/ # apk info -vv
WARNING: opening from cache https://dl-cdn.alpinelinux.org/alpine/v3.18/main: No such file or directory
WARNING: opening from cache https://dl-cdn.alpinelinux.org/alpine/v3.18/community: No such file or directory
alpine-baselayout-3.4.3-r1 - Alpine base dir structure and init scripts
alpine-baselayout-data-3.4.3-r1 - Alpine base dir structure and init scripts
alpine-keys-2.4-r1 - Public keys for Alpine Linux packages
apk-tools-2.14.0-r2 - Alpine Package Keeper - package manager for alpine
busybox-1.36.1-r2 - Size optimized toolbox of many common UNIX utilities
busybox-binsh-1.36.1-r2 - busybox ash /bin/sh
ca-certificates-20230506-r0 - Common CA certificates PEM files from Mozilla
ca-certificates-bundle-20230506-r0 - Pre generated bundle of Mozilla certificates
libc-utils-0.7.2-r5 - Meta package to pull in correct libc
libcrypto3-3.1.3-r0 - Crypto library from openssl
libssl3-3.1.3-r0 - SSL shared libraries
musl-1.2.4-r1 - the musl c library (libc) implementation
musl-utils-1.2.4-r1 - the musl c library (libc) implementation
openssl-3.1.3-r0 - Toolkit for Transport Layer Security (TLS)
scanelf-1.3.7-r1 - Scan ELF binaries for stuff
ssl_client-1.36.1-r2 - EXternal ssl_client for busybox wget
zlib-1.2.13-r1 - A compression/decompression Library

Doesn't look like tzdata was ever installed... 🤔

[jicho]

Same here...

I have TZ=Europe/Amsterdam in my docker compose in combination with DIUN_WATCH_SCHEDULE=0 7 * * *

Result is since the latest release that the scheduler runs at 8 local time... Before the update the scheduler runs, as expected, at 7.

[crazy-max]

With Go 1.20 it works as expected:

diun  | TZ Europe/Paris
diun  | zone CET
diun  | offset 3600

[crazy-max]

Looks related to this change golang/go@627765a in Go 1.21.

Installing tzdata package in the image seems to work so this is an issue with embedded tzdata from Go.

[Fayyaadh]

Looks related to this change golang/go@627765a in Go 1.21.

Installing tzdata package in the image seems to work so this is an issue with embedded tzdata from Go.

So will there be an updated image with a fix, or how do end users deal with the issue?

[Guiorgy]

@Fayyaadh As mentioned, installing tzdata manually is a temporary solution. Just run the following (replace Diun with the name of your container):

docker exec -it Diun apk add --no-cache tzdata

After it's installed, restart the container:

docker restart Diun

[Fayyaadh]

@Guiorgy thank you, sir, I've done that now and will see if the notification goes out at the correct time.

[Guiorgy]

@Guiorgy thank you, sir, I've done that now and will see if the notification goes out at the correct time.

Forgot to mention 1 thing, you'll probably need to restart (not recreate) the container for the timezone to apply, for example my logs:

Wed, 27 Mar 2024 10:23:09 UTC INF Next run in 4 hours 37 minutes (2024-03-27 15:00:14.30801095 +0000 UTC)
Wed, 27 Mar 2024 10:23:20 UTC WRN Caught signal terminated
Wed, 27 Mar 2024 14:23:23 +04 INF Starting Diun version=v4.27.0
...
Wed, 27 Mar 2024 14:23:27 +04 INF Cron initialized with schedule 0 15 * * *
Wed, 27 Mar 2024 14:23:27 +04 INF Next run in 36 minutes 41 seconds (2024-03-27 15:00:09.353141199 +0400 +04)

[Fayyaadh]

@Guiorgy thank you, sir, I've done that now and will see if the notification goes out at the correct time.

Forgot to mention 1 thing, you'll probably need to restart (not recreate) the container for the timezone to apply, for example my logs:

Wed, 27 Mar 2024 10:23:09 UTC INF Next run in 4 hours 37 minutes (2024-03-27 15:00:14.30801095 +0000 UTC)

Wed, 27 Mar 2024 10:23:20 UTC WRN Caught signal terminated

Wed, 27 Mar 2024 14:23:23 +04 INF Starting Diun version=v4.27.0

...

Wed, 27 Mar 2024 14:23:27 +04 INF Cron initialized with schedule 0 15 * * *

Wed, 27 Mar 2024 14:23:27 +04 INF Next run in 36 minutes 41 seconds (2024-03-27 15:00:09.353141199 +0400 +04)

I think it worked without restarting the container. Running the date command inside the container now shows my local timezone, not UTC anymore.

[kristof-mattei]

@Guiorgy thank you, sir, I've done that now and will see if the notification goes out at the correct time.

Forgot to mention 1 thing, you'll probably need to restart (not recreate) the container for the timezone to apply, for example my logs:

Wed, 27 Mar 2024 10:23:09 UTC INF Next run in 4 hours 37 minutes (2024-03-27 15:00:14.30801095 +0000 UTC)

Wed, 27 Mar 2024 10:23:20 UTC WRN Caught signal terminated

Wed, 27 Mar 2024 14:23:23 +04 INF Starting Diun version=v4.27.0

...

Wed, 27 Mar 2024 14:23:27 +04 INF Cron initialized with schedule 0 15 * * *

Wed, 27 Mar 2024 14:23:27 +04 INF Next run in 36 minutes 41 seconds (2024-03-27 15:00:09.353141199 +0400 +04)

I think it worked without restarting the container. Running the date command inside the container now shows my local timezone, not UTC anymore.

It never had the tzdata installed, so while date might pick it up, it is a new process after all, I'm not sure the go process picks it up.

[Guiorgy]

@kristof-mattei The cron was triggered correctly, so it works in this case:

DIUN_WATCH_SCHEDULE: '0 15 * * *'

2024-03-28T11:00:53 Thu, 28 Mar 2024 15:00:53 +04 INF Cron triggered