Re: buster netinst timezone

[David Wright <deblis@lionunicorn.co.uk>]

On Wed 28 Aug 2019 at 14:08:47 (-0400), Michael Stone wrote:
> On Wed, Aug 28, 2019 at 12:25:32PM -0500, David Wright wrote:
> > On Mon 12 Aug 2019 at 08:38:47 (-0400), Greg Wooledge wrote:
> > > The first one is the /etc/timezone file, which as you say, is a
> > > simple text file that a (root) user can edit.  I believe this is the
> > > backward-compatibility one.
> > 
> > And that's the one I find useful, in that a lot of applications honour
> > a value for TZ, which needs to be the text version. I always have a
> > link to /etc/timezone as ~/.timezone, and TZ is set to its value in
> > my startup files, which makes it easy to run a session in a
> > contradictory timezone if I wish.
> > 
> > > The second one is the /etc/localtime symbolic link, which needs to point
> > > to an existing binary time zone data file in /usr/share/zoneinfo.  The
> > > symbolic link can be re-pointed by hand; the binary data file should not
> > > be edited by hand.
> > 
> > I assume the system is interested in this one because it needs the
> > actual rules and not just the name of the timezone. Otherwise the
> > system wouldn't be able to junp the clocks at the appropriate times.
> 
> You're making a distinction that doesn't exist. The text value in TZ or
> /etc/timezone should match a filename in /usr/share/zoneinfo. If it
> doesn't then you'll get incons[is]tent dates.

Well, yes, I'm assuming that users are playing fair and stick to
using filenames that exist and not, say, TZ=Texas/Paris. Further
down my post (2 back) it said "… the string UTC
(the alternatives are simply the names of the files in
/usr/share/zoneinfo, including subdirectories)." Is that the
distinction you meant?

So I'm not sure whether that was what you were trying to say;
forgive me if I assume you might have meant to write, "If
/etc/timezone specifies a different timezone filename from the
file that /etc/localtime is linked to, then you'll get
inconsistent dates".

AIUI, for a system running systemd, only the /etc/localtime link¹
matters for that part of the system. And it only seems to matter²
if you set the clock yourself with, say, timedatectl set-time foo
because the time "foo" will be converted to UTC using that link
and then be applied to the system time and the RTC as well. OTOH if
ntp sets the clock for you, then I assume you'll get the correct
time response from the servers anyway.

Of course, if you play fast and loose with /etc/localtime and you
are running with the RTC on some local time, there are likely to be
problems. But then, systemd doesn't claim to fully support a non-UTC
RTC anyway.

If you set TZ to a timezone before running programs, the programs
should honour it, but they might vary in exactly how they interpret it.
If TZ is unset, and programs wish to know the system's default
timezone, then programs using the gnu C library should be following
the /etc/localtime link. If they were to read /etc/timezone instead,
the program would just behave as if TZ had been set to that value.

But so what? Programs should be able to run in any timezone, and will
just display timedates as appropriate. If they intercommunicate with
other programs, they should be using UTC (or timezone-aware
timestamps) in any case. For example, anyone running a banking app
might be use a bank account system operating in a different timezone.
Both are expected to know what time it really is.

But in the context of what sparked Greg's comment, it was intended
that anyone setting the timezone manually with one or both of these
files would run dpkg-reconfigure tzdata as soon as possible
thereafter. The problem in the installation process is that not all
the usual commands are available, and some people might not be aware
of the difference between the filesystem as seen by the installer
(/) and the future filesystem being installed (/target/).

The OP wanted UTC set as the system timezone as soon as possible,
and claimed the d-i didn't offer it (which is not my experience).
But /etc/localtime is a better bet to set than /etc/timezone (which
I suggested), because   dpkg-reconfigure tzdata   prioritises it.
It was an off-the-cuff suggestion: I've always just set the timezone
I'm in, like most people.

Having glanced at the configuration scripts, it does look as though
one alternative for the OP to run a system entirely on UTC is merely
to remove both /etc/localtime and /etc/timezone, though I can see no
reason to prefer that over UTC selected from the debconf screens.

> There's a POSIX spec for
> encoding quite a lot of information into TZ, but that's practically
> obsolete.

Sure, I'm not considering this and have never used it.

¹ And it must be a link.
    https://wiki.debian.org/TimeZoneChanges
  appears to be way out of date.

² Matters in the sense of messing up the computer's knowledge
  of what time it is in the rest of the world.

Cheers,
David.