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.