Support for timezones?

[larskruckow]

I can see that it runs with default UTC time.
This makes it difficult to time everything to specific local times (especially with daylight saving)
I suggest adding support for setting the timezone it runs under in the environment

[m90]

In case you are able to set the host system's time (or just want to align the container time and the host time) you can mount /etc/timezone and /etc/localtime (readonly is enough) into the container:

➜  ~ docker run --rm -it --entrypoint ash offen/docker-volume-backup:latest 
~ # date
Sat Oct 23 13:29:31 UTC 2021
➜  ~ docker run --rm -it --entrypoint ash -v /etc/timezone:/etc/timzeone:ro -v /etc/localtime:/etc/localtime:ro offen/docker-volume-backup:latest
~ # date
Sat Oct 23 15:29:31 CEST 2021

Does this solve your usecase?

---

In case the image should support setting an arbitrary timezone through a TZ environment variable, it would need to install the tzdata package, which weighs in at 3.3MB and would add ~20% on top of the current image size, so I would like to avoid this in case it's possible.

[larskruckow]

Thanks.
Don't know why I didn't think of that.
I totally see your point with the increased size.
I can confirm that using the host time cron then runs at expected time as is on the host.

[m90]

I added a section on this to the README. Thanks for raising this.

[calebdjgreen]

This solution does not work any longer due to localtime being a symbolic link in newer distributions.

Mounting this volume along with the other two fixed it for me, but this may not always be required:

/usr/share/zoneinfo:/usr/share/zoneinfo:ro

Seems like adding the tzdata package may be easier in the long run for simplicities' sake, but I understand not wanting to bloat the image.

See https://serverfault.com/questions/683605/docker-container-time-timezone-will-not-reflect-changes for more info and proposed solutions.

[m90]

Seems like adding the tzdata package may be easier in the long run for simplicities' sake, but I understand not wanting to bloat the image.

Is it as simple as apk add tzdata instead of mounting the required files? In case yes, I still wouldn't want to add it to the image, however mentioning it in the docs might be helpful. In the end, people could use their own image off a very simple Dockerfile like this

FROM offen/docker-volume-backup:v2
RUN apk add tzdata --no-cache

[mmichalak-swe]

@m90 This is a wonderful tool you've built, and I think it would greatly benefit from the tzdata package included in the image by default.

I did some testing and would like to share the results, both custom images were created with the following Dockerfile:

FROM offen/docker-volume-backup:v2.47.2
RUN apk add tzdata --no-cache

architecture	image tag	size (uncompressed on host)	total vulnerabilities in trivy scan	trivy scan breakdown
linux/arm64	v2.47.2	42.8 MB	7	offen/docker-volume-backup:v2.47.2 (alpine 3.23.3) (alpine) Total: 2 — UNKNOWN: 0, LOW: 0, MEDIUM: 1, HIGH: 0, CRITICAL: 1 usr/bin/backup (gobinary) Total: 5 — UNKNOWN: 0, LOW: 2, MEDIUM: 3, HIGH: 0, CRITICAL: 0
linux/arm64	v2.47.2-custom-tzdata	43.3 MB	7	83dd259d5f28 (alpine 3.23.3) (alpine) Total: 2 — UNKNOWN: 0, LOW: 0, MEDIUM: 1, HIGH: 0, CRITICAL: 1 usr/bin/backup (gobinary) Total: 5 — UNKNOWN: 0, LOW: 2, MEDIUM: 3, HIGH: 0, CRITICAL: 0
linux/amd64	v2.47.2	45.1 MB	7	offen/docker-volume-backup:v2.47.2 (alpine 3.23.3) (alpine) Total: 2 — UNKNOWN: 0, LOW: 0, MEDIUM: 1, HIGH: 0, CRITICAL: 1 usr/bin/backup (gobinary) Total: 5 — UNKNOWN: 0, LOW: 2, MEDIUM: 3, HIGH: 0, CRITICAL: 0
linux/amd64	v2.47.2-custom-tzdata	45.6 MB	7	d33369e9f755 (alpine 3.23.3) (alpine) Total: 2 — UNKNOWN: 0, LOW: 0, MEDIUM: 1, HIGH: 0, CRITICAL: 1 usr/bin/backup (gobinary) Total: 5 — UNKNOWN: 0, LOW: 2, MEDIUM: 3, HIGH: 0, CRITICAL: 0

Alpine Linux 3.23 aarch64 tzdata - installed size, 436.5KiB
Alpine Linux 3.23 x86 tzdata - installed size, 436.5KiB

A difference of ~500kB when the image is uncompressed is negligible, with the added utility far outweighing the cost of a slightly larger image (less than 1.5% larger when uncompressed, even less of a difference when compressed), with no increase in vulnerabilities with the addition of the tzdata package. The documentation could be simplified, overall usage more intuitive, and in-line with other popular container images. I run a number of popular apps and this is a first for me, all the others allow for timezone being set by a variable (usually TZ). I think for something as critical as time of a backup, this should be implemented.

Thank you for all of your work on this project, it really is a fantastic tool.

PR to add tzdata -> #748