On Wed, 28 Aug 2019 at 19:25 David Wright <deb...@lionunicorn.co.uk> wrote:
> On Mon 12 Aug 2019 at 08:38:47 (-0400), Greg Wooledge wrote: > > On Sat, Aug 10, 2019 at 12:16:04PM -0500, David Wright wrote: > > > If you're desparate to get the timezone altered earlier in your > > > installation process, you could always do it manually: try switching > > > to VC2 and editing the file /target/etc/timezone to the string UTC > > > (the alternatives are simply the names of the files in > > > /usr/share/zoneinfo, including subdirectories). Obviously wait until > > > the file exists. (I've not tried this so I don't know when that is.) > > > > I'm skeptical that this would be sufficient. Debian actually stores the > > system's default timezone in *two* different places, using two completely > > different mechanisms. I have been led to believe that one of these is > > "standard" for GNU/Linux-based systems, and the other is for backward > > compatibility. > > Yes, you're right. > > > wooledg:~$ ls -ld /etc/*time* > > -rw-r--r-- 1 root root 46 Apr 10 2017 /etc/adjtime > > lrwxrwxrwx 1 root root 36 Apr 1 08:58 /etc/localtime -> > /usr/share/zoneinfo/America/New_York > > -rw-r--r-- 1 root root 17 Apr 1 08:58 /etc/timezone > > > > 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. > > > Running dpkg-reconfigure tzdata changes both of these, so that all the > > programs work, regardless of which one they choose to honor. Manually > > changing just *one* of them would probably leave the system in an > > inconsistent state, where some programs display the correct time zone, > > and others do not. > > Well, a system running on a UTC hardware clock might have different > applications displaying different times, and writing their logs > accordingly, but the effects shouldn't be damaging. In fact, that > is exactly what is happening during the installation itself: the > major part of the log is in UTC, interspersed with segments in > local time from the likes of useradd and groupadd. > > I couldn't speak for users who have a non-UTC clock. > > I would expect anyone using my desparate [sic] tip would confirm > their timezone in the Debian™ manner as soon as practicable. > I just checked the link/file on a recently-installed buster, and the > timestamps indicate that they're created at the start of the main > tranche of package installation, when /var/log/syslog shows¹ > > Aug 22 01:19:31 in-target: Setting up tzdata (2019b-0+deb10u1) ... > Aug 22 01:19:31 in-target: > Aug 22 01:19:33 in-target: > Aug 22 01:19:33 in-target: Current default time zone: 'America/Chicago' > Aug 22 01:19:33 in-target: Local time is now: Wed Aug 21 20:19:33 CDT > 2019. > Aug 22 01:19:33 in-target: Universal Time is now: Thu Aug 22 01:19:33 UTC > 2019. > Aug 22 01:19:33 in-target: Run 'dpkg-reconfigure tzdata' if you wish to > change it. > Aug 22 01:19:33 in-target: > Aug 22 01:19:33 in-target: Setting up linux-image-4.19.0-5-686-pae > (4.19.37-5+deb10u2) ... > > As dpkg gets set up around the same point, I suppose one could try running > # /target/usr/sbin/dpkg-reconfigure tzdata > in a VC at any time after this, though one might need to wait for a > pause in proceedings (like the popcon question) to avoid any file locking. > > AFAICT the clock question at the end (UTC yes/no) only involves adjtime. > > > I don't have any kind of statistics for how many programs use one vs. > > the other. It's not trivial to find out. > > I guess it ought to depend on whether the program is concerned only > with the here and now (use timezone), or whether it takes into account > past history. Precisely 24 weeks ago, the wall time was the same in > the afternoon as now (though someone in the UK would disagree). > 25 weeks ago, it was still morning, an hour earlier. For that > determination, you want the file pointed to by localtime. > > ¹ Note that tzdata gets installed and set up twice, the first time > being the .deb from the iso, the second from the mirror. The log from > the first time looks like > > Aug 22 00:56:21 debootstrap: Setting up tzdata (2019a-1) ... > Aug 22 00:56:23 debootstrap: > Aug 22 00:56:23 debootstrap: Current default time zone: 'Etc/UTC' > Aug 22 00:56:23 debootstrap: Local time is now: Thu Aug 22 00:56:23 > UTC 2019. > Aug 22 00:56:23 debootstrap: Universal Time is now: Thu Aug 22 00:56:23 > UTC 2019. > Aug 22 00:56:23 debootstrap: Run 'dpkg-reconfigure tzdata' if you wish to > change it. > Aug 22 00:56:23 debootstrap: > Aug 22 00:56:23 debootstrap: Setting up libpam0g:i386 (1.3.1-5) ... > > Cheers, > David. > >
