Hi Chris,
On Mon Sep 28, 2026 at 10:13 PM CEST, Chris Lamb wrote:
Thanks for your email. It actually made me look into the differences
between the two — I am not sure I had considered this at all before,
and had assumed they were some kind of internal alias… if I thought
about it at all.
That's very nice to hear :)
In practice, TZ=UTC and TZ=UTC0 do behave identically, but using UTC0
bypasses any kind of lookup in your timezone database. It appears that
glibc can parse "UTC0" internally, whilst "UTC" will require poking in
/usr/share/zoneinfo. (Similar with "Etc/UTC"). Perhaps if you don't
have tzdata installed, "UTC" won't work?
I will say that "UTC0" will appear unfamiliar to most developers, so
saving one disk lookup — that is probably already cached! — is
probably a little silly in a build of a Debian package.
Oh, that's interesting. One day in the future maybe I'll look more into
this implementation quirks!
I also looked up some info in the POSIX standard, and I found this at
<https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html>,
where it basically says that the TZ format should be
std offset [dst [offset][, rule]]
where `std` and `offset` are required. `std` in our case is "UTC", while
`offset` is "0". In particular the definition of `offset` says "The hour
shall be required and may be a single digit. The offset following std
shall be required."
So `TZ=UTC` is technically invalid, as it misses the required offset,
but on glibc it happens to work anyway.
I think I'll hence go with `UTC0`, not really for the avoided disk
lookup but because now that I know I'd rather not willfully violate the
specs -- even though the skipped disk access is a nice side effect :)
Still, interesting to know. :) Thanks again for prompting me to look
it up.
Thanks to you for reporting the bug in the first place!
