Possible bug in timezone naming

Getting Help
1

Hi, I am thrilled to see Restic 0.19.0 Released. Thanks to all the authors for your great work!

I updated my installation and saw this text below the list of snapshots:

Timestamps shown in CEST timezone

It’s about the “CEST” in this output. The time is shown as 2025-01-31 23:00:34 in the text output and as "backup_start":"2025-01-31T23:00:34.220633311+01:00" in the JSON output (restic snapshots <hash> --json). Both are (in a way) correct and mean 23:00:34 Central European Time (CET) or UTC+01:00 and not CEST (i.e. Central European Summer Time).

So the note about the timezone is only correct for the more recent timestamps (UTC+2:00). This kind of timezone name changes between standard and daylight saving time. What stays the same throughout the year is the IANA timezone. That key would be “Europe/Berlin” in my case. So I think, this note is more confusing than helpful.

  • restic 0.19.0
  • command restic snapshots

PS: Funny that @fd0 mentioned time zones in the video Alex on FLOSS Weekly

2

That zone in the output is currently determined for the current time, but that’s indeed incorrect in other parts of the year. The only simple fix I see is to use the timezone location provided by Go, which would result in output like the following depending on on your timezone configuration. The “Local” timezone variant happens if there’s not TZ environment variable and Go just looks at /etc/localtime. It’s probably not ideal but probably good enough to fulfill its purpose.

Timestamps shown in UTC timezone
Timestamps shown in Local timezone
Timestamps shown in Europe/Berlin timezone
3

Fix is in snapshots: show location name instead of current timezone by MichaelEischer · Pull Request #21877 · restic/restic · GitHub

4

Thanks @MichaelEischer for the quick reaction! The fix looks good to me. I agree that the IANA identifier (“location”) is the best choice for what is meant. As far as I know, /etc/localtime is the right place to look for this information.

Just as a side note: the location is not in local language (e.g. Europe/Rome) and may contain underscores (e.g. America/New_York).

5

TL;DR: Correct handling of times is difficult and I think some edge cases are not properly treated by restic :wink:

It might be a bit of nitpicking, but the time format used within restic e.g. for the snapshot creation time is in fact inaccurate and this poses not only display inaccuracies, but also inaccurate behavior for forget - which I think can be at least annoying if not critical.

The problem is, as @noeck correctly points out, that the time zone is not stored. Instead only a local time is stored and the time shift to UTC. This allows to exactly calculate the global point-in time (e.g. by transforming to UTC). However, due to changes in daylight saving, this cannot be uniquely mapped to a single time zone in every case and therefore can be ambiguous.

Not having the time zone is a problem if you want to compute time deltas like “1 day”. Normally, this equals 24h, but if you have a change in daylight saving, e.g. switch from summer to winter time, this is no longer true - here days can be 23h or 25h. (The same applies “weeks” or “months”)

Think of a server doing each day a backup at 01:00h local time with daylight saving changes and using a retention with restic forget –keep-within 1d.If “1 day” is computed as you typically think, this would keep exactly one snapshot. If, however, “1 day” is always taken as 24h, this could mean that you normally keep 1 snapshot, but once a year, you don’t. This can be very surprising for users or even pose critical problems!

Time libraries which are accurate about time deltas like jiff(Rust) or temporal(JavaScript) take this into account and forbid to compute time deltas without a timezone given - and dealing with the restic stored time format gets complicated.

I do think that restic does not take 1dalways correctly - which is inaccurate and can lead to surprising results. At least it should be documented somewhere as I think the repo format won’t be easily changed..

UPDATE: I thought restic does take 1d always as 24h which - after reading the implementation - seems to be not true. However, there are cases involving different time zones where restic will treat 1d not correctly.

6

Small user-facing thing: if restic prints the location name there, it might be worth saying “timezone location” rather than just “timezone”. I’d read Europe/Berlin correctly, but “Local” is less clear unless you already know it comes from /etc/localtime. Still much less misleading than showing the current CEST label for old winter snapshots.

7

I’ve tweaked the timezone wording a bit, see snapshots: improve wording for timezone information by MichaelEischer · Pull Request #21913 · restic/restic · GitHub