[ sorry for slow response, I'm on vacation ]
Andres Freund <andres@anarazel.de> writes:
> That makes sense. As far as I can tell the reason that 12 sometimes ends
> up with the proper timezone is that we shortcut the search by:
> /*
> * Try to avoid the brute-force search by seeing if we can recognize the
> * system's timezone setting directly.
> *
> * Currently we just check /etc/localtime; there are other conventions for
> * this, but that seems to be the only one used on enough platforms to be
> * worth troubling over.
> */
> if (check_system_link_file("/etc/localtime", &tt, resultbuf))
> return resultbuf;
> which is actually a behaviour changing, rather than just an
> optimization, when there's a lot of equivalently scoring timezones.
Sure, that is intentionally a behavior change in this situation.
The theory is that if "Etc/UCT" is what the user put in /etc/localtime,
then that's the spelling she wants. See 23bd3cec6.
But it seems to me that this code is *not* determining the result in
Christoph's case, because if it were, it'd be settling on Etc/UTC,
according to his followup report that
>> lrwxrwxrwx 1 root root 27 Mär 28 14:49 /etc/localtime -> /usr/share/zoneinfo/Etc/UTC
I'm not too familiar with what actually determines glibc's behavior
on Debian, but I'm suspicious that there's an inconsistency between
/etc/localtime and /etc/timezone. We won't adopt the spelling we
see in /etc/localtime unless it agrees with the observed behavior of
localtime(3).
regards, tom lane