Realized restic snapshots are using user’s TZ environment variable (probably for convenience).
But it recently caused some confusion in our multi-user environment. Multiple users had different TZ set on their shells, some not aware, got different times displayed on restic snapshots command, without any hints about timezone.
Data seems to be included in the snapshot data already:
~> restic cat snapshot 1b4e5670 | grep time
"time": "2025-08-22T08:11:00.887849385Z",
I can craft a PR, but first 2 questions:
Would it make sense to add it to restic snapshots output, or was it a calculated decision to remove timezone info?
Is there a backwards-compatibility concern on TUI? (Changing the output might break scripts parsing non-json output etc)
The text output is not considered as stable. For commands where there’s no JSON output, I’d advise to limit unnecessary modifications, but for the others it’s fine to change it as long as there’s a reason. (I’m not entirely sure what timestamp format is included in the JSON output of the snapshots command. That ideally shouldn’t change.)
No idea ^^ , timezone handling so far is somewhat inconsistent in restic. What complicates things is that forget determines the day at which a snapshot was created, based on the timezone with which it was created. So I’m wondering whether it would be best for the snapshot command to just show the timestamp included in the snapshot and not convert it to local time.
If I understand correct, that one never changes and keeps the UTC timestamp.
I am total potato on Golang, but tried to do a small change on the snapshots output (link) which won’t result as confusing as current status IMHO. Could you check if it makes sense?
Identifying the day at which a snapshot was made is actually less obvious than one would think. For example 2025-08-25T01:30+02:00 was on 2025-08-24 according to UTC and on 2025-08-25 when accounting for the timezone. Users most likely expect that the notion of day matches that of their timezone. The correct behavior quickly gets complex when factoring in things like daylight saving time. So there are effectively two options: either use the local timezone of the user calling forget or use the time offset from the timestamp. The latter is definitely less brittle as it won’t be influenced by who runs restic.
I’m actually wondering whether we should stop converting the timestamp to local time altogether (no idea whether that would be better or worse). Explicitly showing the user their own local timezone at each timestamp feels a bit redundant.
Just using UTC would be a solution, but this will also need an info somewhere in the snapshot list (might be a one-line message at the bottom of the output), something like “all timestamps are in UTC”. Otherwise “is this 10:00:00 my local time, or UTC?” question will be still asked by a single user who is listing snapshots. (But I must say this exact confusion already exists for current state while there is no TZ info visible.)
So, not an easy choice.
My problem was 2 users with different timezones, seeing different timestamps on snapshot list, thus getting confused “When did this specific snapshot get created?”. Which is getting solved by this change, because it reminds users their timezones, and one user can see “ah it’s 10:00:00 on my timezone, which is same time 12:00:00 on yours”.
I would appreciate an option to use UTC for everything. I’m backing up several computers in different time zones, and my laptop changes time zones frequently when I travel. It would be simpler for me if everything is in UTC. Perhaps this is as simple as running restic like this (when TZ is not already UTC)?
TZ=UTC restic backup /path/to/backup
Otherwise, a CLI option such as –tz=utc would be nice.
