On Fri, Jul 22, 2022 at 3:06 AM Robert Elz via tz <tz@iana.org> wrote:
    Date:        Fri, 22 Jul 2022 09:55:44 +0200
    From:        Florian Weimer via tz <tz@iana.org>
    Message-ID:  <877d45funz.fsf@oldenburg.str.redhat.com>

  | It's just a myth that the IANA tz identifiers are internal data
  | invisible to users.  Real systems do not work this way.

android seems to, I have never seen a TZ string of any kind in normal
use of any of my android devices - yet I know it is in there, in some
form, somewhere.

(off-topic from ubuntu's ui problems at this point, but...)

yeah, Android uses a system property to communicate system-wide timezone changes. in libc, where tzcode checks the environment variable, we check the system property.

annoyingly we _also_ check the environment variable, which is useful for command-line stuff (where it's a workaround for the lack of functions in POSIX that take an explicit timezone). this shows up in profiles even; if you profile the logcat command which takes a bunch of timestamps and formats them, it spends a depressing amount of time in getenv(). the system properties stuff is cheap to ask "has it changed?" after your first lookup. theoretically i could make the environment functions try to keep track of changes, but putenv() breaks that. (environ is no great help either.) i guess i could look for putenv() with "TZ=" and have another "all bets are off" flag, but, well, i've never been quite annoyed enough by logcat's performance issues to try to go there.
 
The real issue is developer laziness / lack of time, combined with the
fact that (even on systems that don't attempt to hide that tzdb timesone
identifier) users almost never see it, it tends to get used once when
the system is installed, then ignored forever after.   That tends to make
it a low priority for many systems to provide a better solution.

kre