buster netinst timezone

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

buster netinst timezone

Russell L. Harris-2
The netinst cd image for Buster 10.0.0 does not offer a UTC option for
English -> United States.

This is a critical bug; every installer without exception should offer UTC.

Is there a work-around, so that files written during the
installation process have the correct datestamp?

One suggestion was to select English -> Great Britain, but this
possibly has other consequences regarding locale settings.

Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

Charlie Kravetz-2
On Fri, 9 Aug 2019 21:38:23 +0000
"Russell L. Harris" <[hidden email]> wrote:

>The netinst cd image for Buster 10.0.0 does not offer a UTC option for
>English -> United States.
>
>This is a critical bug; every installer without exception should offer UTC.
>
>Is there a work-around, so that files written during the
>installation process have the correct datestamp?
>
>One suggestion was to select English -> Great Britain, but this
>possibly has other consequences regarding locale settings.
>

The installer attempts to allow all actual timezones for a country. The
United States does not actually have a timezone called UTC.

Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

John Hasler-3
Charlie Kravetz writes:
> The installer attempts to allow all actual timezones for a
> country. The United States does not actually have a timezone called
> UTC.

UTC isn't a timezone.  It should be offered, though.
--
John Hasler
[hidden email]
Elmwood, WI USA

Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

Patrick Bartek-2
In reply to this post by Russell L. Harris-2
On Fri, 9 Aug 2019 21:38:23 +0000
"Russell L. Harris" <[hidden email]> wrote:

> The netinst cd image for Buster 10.0.0 does not offer a UTC option for
> English -> United States.

Mine did.  IIRC it was part of the timezone choice at install. Last in
the list. Stock Buster Netinstall CD. I don't use UTC, but local time
instead since at one time I used to dual boot this system with
WindowsXP, and it didn't play nice with UTC.  Never changed it after I
moved XP to Virtualbox.

> This is a critical bug; every installer without exception should offer UTC.
>
> Is there a work-around, so that files written during the
> installation process have the correct datestamp?
>
> One suggestion was to select English -> Great Britain, but this
> possibly has other consequences regarding locale settings.

I used the "text" install option instead of the artsy-fartsy GUI
to install Buster in Virtualbox.  Install went fine.  No problems.

I did both a basic terminal only system which I later added xorg and the
Openbox window manager, etc. and a default LXDE desktop as another VM.
I avoid GNOME like the plague.  Stopped using it when I left Fedora 12
behind in favor of Debian some . . . what? . . . 7 years ago?

B

Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

David Wright-3
In reply to this post by Russell L. Harris-2
On Fri 09 Aug 2019 at 21:38:23 (+0000), Russell L. Harris wrote:

> The netinst cd image for Buster 10.0.0 does not offer a UTC option for
> English -> United States.
>
> This is a critical bug; every installer without exception should offer UTC.
>
> Is there a work-around, so that files written during the
> installation process have the correct datestamp?
>
> One suggestion was to select English -> Great Britain, but this
> possibly has other consequences regarding locale settings.

It's not clear to me why you couldn't select this, nor why your files
would have the wrong timestamp. Here's some output from a buster
installation on acer. As it was my first, I kept the typescript.

Current output from acer itself:

✄✄✄✄✄✄✄✄

acer!david 22:24:52 ~ $ cat /etc/debian_version
10.0
acer!david 22:24:55 ~ $ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
acer!david 22:24:57 ~ $ ls -l /var/log/installer/
total 864
drwxr-xr-x 2 root root   4096 Jul 12 11:48 cdebconf
-rw-r--r-- 1 root root  33297 Jul 12 11:48 hardware-summary
-rw-r--r-- 1 root root    152 Jul 12 11:48 lsb-release
-rw-r----- 1 root adm  250698 Jul 12 11:48 partman
-rw-r--r-- 1 root root  76445 Jul 12 11:48 status
-rw-r----- 1 root adm  507777 Jul 12 11:48 syslog
acer!david 22:24:59 ~ $ TZ=UTC0 ls -l /var/log/installer/
total 864
drwxr-xr-x 2 root root   4096 Jul 12 16:48 cdebconf
-rw-r--r-- 1 root root  33297 Jul 12 16:48 hardware-summary
-rw-r--r-- 1 root root    152 Jul 12 16:48 lsb-release
-rw-r----- 1 root adm  250698 Jul 12 16:48 partman
-rw-r--r-- 1 root root  76445 Jul 12 16:48 status
-rw-r----- 1 root adm  507777 Jul 12 16:48 syslog
acer!david 22:25:00 ~ $

✄✄✄✄✄✄✄✄

And here are clock-y extracts from the typescript of installing
buster onto acer last month (captured on wren via ssh). The
box you want is the fourth (I select Central):

✄✄✄✄✄✄✄✄

Script started on Fri 12 Jul 2019 11:12:26 AM CDT
(This is /home/david/.bashrc 2019 July 10)
(This is /home/david/.bash-1-wren 2019 January 26 on stretch)
(This is /home/david/.bash-u-usbs 2019 June 01)
(This is /home/david/.bash-t-transfers 2019 June 17 enp1s0)
(This is /home/david/.bash-w-web 2019 June 19)
(This is /home/david/.bash-9-wren 2019 June 13 @1600x900)
wren!david 11:15:26 ~ $ installer-on 192.168.1.201
The authenticity of host '192.168.1.201 (192.168.1.201)' can't be established.
RSA key fingerprint is SHA256:YFp6hlF+Et+KjrJFJZHVnf23G+HORSXMY9Hr3OaGubc.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.201' (RSA) to the list of known hosts.
installer@192.168.1.201's password:
/var/run/utmp: No such file or directory

┌────────────────────────┤ [!!] Configuring d-i ├─────────────────────────┐
│  │
│ This is the network console for the Debian installer. From here, you  │
│ may start the Debian installer, or execute an interactive shell.  │
│  │
│ To return to this menu, you will need to log in again.  │
│  │
│ Network console option:  │
│  │
│     Start installer  │
│     Start installer (expert mode)  │
│     Start shell  │
│  │
└─────────────────────────────────────────────────────────────────────────┘

[…]


┌───────────────────┤ [?] Configure the clock ├────────────────────┐
│   │
│ The Network Time Protocol (NTP) can be used to set the system's  │
│ clock. The installation process works best with a correctly set  │
│ clock.   │
│   │
│ Set the clock using NTP?   │
│   │
│     <Yes>  <No>   │
│   │
└──────────────────────────────────────────────────────────────────┘

┌────────────────────┤ [.] Configure the clock ├─────────────────────┐
│     │
│ The default NTP server is almost always a good choice, but if you  │
│ prefer to use another NTP server, you can enter it here.     │
│     │
│ NTP server to use:     │
│     │
│ 0.debian.pool.ntp.org_____________________________________________ │
│     │
│      <Continue>     │
│     │
└────────────────────────────────────────────────────────────────────┘

┌───────────────────────┤ [!] Configure the clock ├───────────────────────┐
│  │
│ If the desired time zone is not listed, then please go back to the  │
│ step "Choose language" and select a country that uses the desired  │
│ time zone (the country where you live or are located).  │
│  │
│ Select your time zone:  │
│  │
│    Eastern  │
│    Central  │
│    Mountain  │
│    Pacific  │
│    Alaska  │
│    Hawaii  │
│    Arizona  │
│    East Indiana  │
│    Samoa  │
│    Coordinated Universal Time (UTC)  │
│  │
│     <Go Back>  │
│  │
└─────────────────────────────────────────────────────────────────────────┘

[…]

┌────────────────────┤ [!] Finish the installation ├────────────────────┐
│ │
│ System clocks are generally set to Coordinated Universal Time (UTC). │
│ The operating system uses your time zone to convert system time into │
│ local time. This is recommended unless you also use another operating │
│ system that expects the clock to be set to local time. │
│ │
│ Is the system clock set to UTC? │
│ │
│ <Go Back> <Yes>    <No> │
│ │
└───────────────────────────────────────────────────────────────────────┘

┌───────────────────┤ [!!] Finish the installation ├────────────────────┐
│ │
│  Installation complete │
│ Installation is complete, so it is time to boot into your new system. │
│ Make sure to remove the installation media, so that you boot into the │
│ new system rather than restarting the installation. │
│ │
│ <Go Back> <Continue> │
│ │
└───────────────────────────────────────────────────────────────────────┘

┌────────────────────┤ Finishing the installation ├──────────────────────┐
│ │
│ │
│ Running final-message... │
│ │
└────────────────────────────────────────────────────────────────────────┘

Configuring network...
Running netcfg-copy-config...
Gathering information for installation report...
Unmounting file systems...
Running release-dhcp-lease...
Rebooting into your new system...
Connection to 192.168.1.201 closed by remote host.
Connection to 192.168.1.201 closed.
$
$ exit

Script done on Fri 12 Jul 2019 11:48:55 AM CDT

✄✄✄✄✄✄✄✄

Perhaps you were looking at the timestamps *in* the syslog.
These start out in UTC, but switch to local time while Grub's
prober runs. Here are extracts from /var/log/installer/syslog
on acer:

✄✄✄✄✄✄✄✄

Jul 12 16:03:03 syslogd started: BusyBox v1.30.1
Jul 12 16:03:03 kernel: klogd started: BusyBox v1.30.1 (Debian 1:1.30.1-4)
Jul 12 16:03:03 kernel: [    0.000000] Linux version 4.19.0-5-686 ([hidden email]) (gcc version 8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-5 (2019-06-19)
Jul 12 16:03:03 kernel: [    0.000000] Disabled fast string operations

[…]

Jul 12 16:44:37 grub-installer: info: grub-install ran successfully
Jul 12 16:44:38 in-target: Reading package lists...
Jul 12 16:44:38 in-target:
Jul 12 16:44:38 in-target: Building dependency tree...
Jul 12 16:44:38 in-target:
Jul 12 16:44:38 in-target: Reading state information...
Jul 12 16:44:38 in-target:
Jul 12 16:44:39 in-target: grub-common is already the newest version (2.02+dfsg1-20).
Jul 12 16:44:39 in-target: 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Jul 12 16:44:46 kernel: [ 2509.158052] QNX4 filesystem 0.2.3 registered.
Jul 12 11:44:46 os-prober: debug: running /usr/lib/os-probes/50mounted-tests on /dev/sda1
Jul 12 11:44:47 50mounted-tests: debug: mounted using GRUB ext2 filesystem driver
Jul 12 11:44:47 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/05efi
Jul 12 11:44:47 05efi: debug: Not on UEFI platform

[…]

Jul 12 11:44:53 40grub2: debug: parsing: source $prefix/custom.cfg;
Jul 12 11:44:53 40grub2: debug: parsing: fi
Jul 12 11:44:53 40grub2: debug: parsing: ### END /etc/grub.d/41_custom ###
Jul 12 11:44:53 50mounted-tests: debug: /usr/lib/linux-boot-probes/mounted/40grub2 succeeded
Jul 12 11:44:53 linux-boot-prober: debug: linux detected by /usr/lib/linux-boot-probes/50mounted-tests
Jul 12 16:44:57 linux-boot-prober: debug: running /usr/lib/linux-boot-probes/50mounted-tests
Jul 12 16:44:58 50mounted-tests: debug: running /usr/lib/linux-boot-probes/mounted/40grub /dev/sda1 /dev/sda1 /var/lib/os-prober/mount ext2
Jul 12 16:44:58 50mounted-tests: debug: running /usr/lib/linux-boot-probes/mounted/40grub2 /dev/sda1 /dev/sda1 /var/lib/os-prober/mount ext2

[…]

Jul 12 16:47:59 finish-install: info: Running /usr/lib/finish-install.d/60cleanup
Jul 12 16:48:00 finish-install: info: Running /usr/lib/finish-install.d/65partman-md
Jul 12 16:48:00 finish-install: info: Running /usr/lib/finish-install.d/70mtab
Jul 12 16:48:00 finish-install: info: Running /usr/lib/finish-install.d/90base-installer
Jul 12 16:48:00 finish-install: info: Running /usr/lib/finish-install.d/90console
Jul 12 16:48:00 finish-install: info: Running /usr/lib/finish-install.d/94random-seed
Jul 12 16:48:00 finish-install: info: Running /usr/lib/finish-install.d/94save-logs

✄✄✄✄✄✄✄✄

Cheers,
David.

Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

Russell L. Harris-2
On Fri, Aug 09, 2019 at 10:39:23PM -0500, David Wright wrote:
>It's not clear to me why you couldn't select this, nor why your files
>would have the wrong timestamp. Here's some output from a buster
>installation on acer. As it was my first, I kept the typescript.
...

Thanks, David.  For some reason on my first installation attempt, the
menu hung and did not allow me to select ADVANCE OPTIONS -> EXPERT
INSTALL.  This is a notebook; I may have pressed two keys at one
accidentally.

But on a subsequent attempt, I was able to select EXPERT INSTALL, and
that allows me to specify UTC.  So for this installation, the issue is
resolved.

But I still think that even the non-expert should be allowed, if not
strongly encouraged, to use UTC.

Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

john doe-6
On 8/10/2019 7:42 AM, Russell L. Harris wrote:

> On Fri, Aug 09, 2019 at 10:39:23PM -0500, David Wright wrote:
>> It's not clear to me why you couldn't select this, nor why your files
>> would have the wrong timestamp. Here's some output from a buster
>> installation on acer. As it was my first, I kept the typescript.
> ...
>
> Thanks, David.  For some reason on my first installation attempt, the
> menu hung and did not allow me to select ADVANCE OPTIONS -> EXPERT
> INSTALL.  This is a notebook; I may have pressed two keys at one
> accidentally.
>
> But on a subsequent attempt, I was able to select EXPERT INSTALL, and
> that allows me to specify UTC.  So for this installation, the issue is
> resolved.
>
> But I still think that even the non-expert should be allowed, if not
> strongly encouraged, to use UTC.
>

If I'm not mistaking, this option is offered neer the end of the
non-advance installation.

--
John Doe

Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

deloptes-2
In reply to this post by Russell L. Harris-2
Russell L. Harris wrote:

> But I still think that even the non-expert should be allowed, if not
> strongly encouraged, to use UTC.

Why? The non expert lives somewhere relative to UTC, why should I use UTC.
AFAIK it is always UTC in the background adding or substracting the
timezone and perhaps summer time and other specifics. I do not want to
calculate each time on top of UTC, what the time is.



Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

andreimpopescu
In reply to this post by Russell L. Harris-2
On Vi, 09 aug 19, 21:38:23, Russell L. Harris wrote:
> The netinst cd image for Buster 10.0.0 does not offer a UTC option for
> English -> United States.
>
> This is a critical bug; every installer without exception should offer UTC.
>
> Is there a work-around, so that files written during the
> installation process have the correct datestamp?

It seems to me like you are confusing the hardware clock (the internal
clock of the computer, if it has one), the system clock (the clock of
the operating system) and the timezone (translating the system clock to
the clock shown to users)[1].

On linux the system clock is always set to UTC.

The time(stamps) shown to the user are translated on the fly depending
on the system or user's timezone.

In practice this means there is global timezone set by the administrator
(usually during install, but can be changed with
'dpkg-reconfigure tzdata') and users may also chose their own timezone
as they prefer (think SSH server with users from all over the world).

See for example the output of:

$ ls -l /etc/issue

vs

$ TZ=UTC ls -l /etc/issue

Unless you set your timezone to UTC during the install those two would
show different timestamps.

Depending on whether you are booting some other OS that uses local also
clock internally (e.g. Windows) from the same hardware it might be
necessary to set the hardware clock to the local time of the timezone
you want displayed in that other OS.


What problem are you trying to solve by having the timestamps of the
initial installation be in UTC (which they are anyway)?


[1] It certainly doesn't help that the installer is calling both system
and hardware clock "system clock".

Hope this helps,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

Richard Hector
On 10/08/19 8:49 PM, Andrei POPESCU wrote:
> On Vi, 09 aug 19, 21:38:23, Russell L. Harris wrote:

>> Is there a work-around, so that files written during the
>> installation process have the correct datestamp?
>
> It seems to me like you are confusing the hardware clock (the internal
> clock of the computer, if it has one), the system clock (the clock of
> the operating system) and the timezone (translating the system clock to
> the clock shown to users)[1].
>
> On linux the system clock is always set to UTC.
>
> The time(stamps) shown to the user are translated on the fly depending
> on the system or user's timezone.
That's true of the timestamps that are part of the filesystem metadata,
but not true of any timestamps included in the file content itself - eg
as part of log lines. I don't know which Russell is concerned about.

Richard


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

Russell L. Harris-2
In reply to this post by deloptes-2
On Sat, Aug 10, 2019 at 09:14:08AM +0200, deloptes wrote:
>Why? The non expert lives somewhere relative to UTC, why should I use UTC.
>AFAIK it is always UTC in the background adding or substracting the
>timezone and perhaps summer time and other specifics. I do not want to
>calculate each time on top of UTC, what the time is.

To each his own.  I remember the explanation of an airline pilot as to
the reason he kept his wristwatch set to GMT.  Constantly crossing
from one time zone to another, he said that the mental conversion
quickly became automatic and painless, and was much less trouble than
constantly resetting his watch.

Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

deloptes-2
Russell L. Harris wrote:

> To each his own.  I remember the explanation of an airline pilot as to
> the reason he kept his wristwatch set to GMT.  Constantly crossing
> from one time zone to another, he said that the mental conversion
> quickly became automatic and painless, and was much less trouble than
> constantly resetting his watch.

my question was, why this should not be behind "expert". A non expert or
even an expert would choose his time zone.
I think time ago in the time zone selection window the GMT/UTC existed as
possible selection.

Also after installation once can adjust the time zone anyway.



Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

Russell L. Harris-2
In reply to this post by Richard Hector
On Sat, Aug 10, 2019 at 08:56:01PM +1200, Richard Hector wrote:
>That's true of the timestamps that are part of the filesystem metadata,
>but not true of any timestamps included in the file content itself - eg
>as part of log lines. I don't know which Russell is concerned about.

In the non-expert mode, the Buster installer suggested that if the
user requires a time zone other than those shown, he should go back to
the COUNTRY menu and select a country in the time zone he desired.

One thing which concerned me about that suggestion was the possibility
of changing the locale settings, with the result that, for example,
the system might be using a British spelling checker rather than an
American spelling checker, and perhaps pounds and pence rather than
dollars and cents.

Why would the installer suggest to the non-expert user such a
complicated fix, rather than presenting to the non-expert user the
same timezone menu presented to the expert user?

As to file creation and access datestamps, what time is shown by, for
example, the "ls -al" command if I select central time zone?  Do I see
Central times, or UTC?  When examining file creation and access times,
I simply wish all files always to be datestamped in UTC.

RLH


Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

Richard Hector
On 10/08/19 9:25 PM, Russell L. Harris wrote:
> On Sat, Aug 10, 2019 at 08:56:01PM +1200, Richard Hector wrote:
>> That's true of the timestamps that are part of the filesystem metadata,
>> but not true of any timestamps included in the file content itself - eg
>> as part of log lines. I don't know which Russell is concerned about.
>
> In the non-expert mode, the Buster installer suggested that if the
> user requires a time zone other than those shown, he should go back to
> the COUNTRY menu and select a country in the time zone he desired.

I think that's fair for a different country - the chances you're
installing in/for the US and want French time are minimal. But I agree
UTC should always be available.

> One thing which concerned me about that suggestion was the possibility
> of changing the locale settings, with the result that, for example,
> the system might be using a British spelling checker rather than an
> American spelling checker, and perhaps pounds and pence rather than
> dollars and cents.
>
> Why would the installer suggest to the non-expert user such a
> complicated fix, rather than presenting to the non-expert user the
> same timezone menu presented to the expert user?

I have to admit, I almost always use expert mode, so I'm not familiar
with what is available in the 'normal' mode.

> As to file creation and access datestamps, what time is shown by, for
> example, the "ls -al" command if I select central time zone?  Do I see
> Central times, or UTC?  When examining file creation and access times,
> I simply wish all files always to be datestamped in UTC.

ls -l will show the timestamps adjusted for your chosen local timezone.
They're stored in UTC.

Unless, of course, you've subverted the system by selecting the UTC
timezone and then set the clock so it looks right locally. Then it will
all be broken.

Richard



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

John Hasler-3
In reply to this post by Russell L. Harris-2
Russel writes:
> As to file creation and access datestamps, what time is shown by, for
> example, the "ls -al" command if I select central time zone?  Do I see
> Central times, or UTC?  When examining file creation and access times,
> I simply wish all files always to be datestamped in UTC.

Make

TZ=":UTC"  ls -al

an alias for "ls -al".
--
John Hasler
[hidden email]
Elmwood, WI USA

Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

David Wright-3
In reply to this post by Russell L. Harris-2
On Sat 10 Aug 2019 at 09:01:27 (+0000), Russell L. Harris wrote:

> On Sat, Aug 10, 2019 at 09:14:08AM +0200, deloptes wrote:
> > Why? The non expert lives somewhere relative to UTC, why should I use UTC.
> > AFAIK it is always UTC in the background adding or substracting the
> > timezone and perhaps summer time and other specifics. I do not want to
> > calculate each time on top of UTC, what the time is.
>
> To each his own.  I remember the explanation of an airline pilot as to
> the reason he kept his wristwatch set to GMT.  Constantly crossing
> from one time zone to another, he said that the mental conversion
> quickly became automatic and painless, and was much less trouble than
> constantly resetting his watch.

I was under the impression that airline pilots were paid enough to buy
two-zone wristwatches, but perhaps the threatened strikes are an
indication that they don't think they are. While they're on strike,
they'll be able to enjoy a holiday from checking the time.

Cheers,
David.

Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

David Wright-3
In reply to this post by Russell L. Harris-2
On Sat 10 Aug 2019 at 09:25:22 (+0000), Russell L. Harris wrote:

> On Sat, Aug 10, 2019 at 08:56:01PM +1200, Richard Hector wrote:
> > That's true of the timestamps that are part of the filesystem metadata,
> > but not true of any timestamps included in the file content itself - eg
> > as part of log lines. I don't know which Russell is concerned about.
>
> In the non-expert mode, the Buster installer suggested that if the
> user requires a time zone other than those shown, he should go back to
> the COUNTRY menu and select a country in the time zone he desired.
>
> One thing which concerned me about that suggestion was the possibility
> of changing the locale settings, with the result that, for example,
> the system might be using a British spelling checker rather than an
> American spelling checker, and perhaps pounds and pence rather than
> dollars and cents.
>
> Why would the installer suggest to the non-expert user such a
> complicated fix, rather than presenting to the non-expert user the
> same timezone menu presented to the expert user?
>
> As to file creation and access datestamps, what time is shown by, for
> example, the "ls -al" command if I select central time zone?  Do I see
> Central times, or UTC?  When examining file creation and access times,
> I simply wish all files always to be datestamped in UTC.

I think that having the entire machine set to UTC for all users is
unusual, but if that's what you want, then it's unlikely that you
don't have root access. Assuming that is so, then the normal course
of action is:

$ sudo /usr/sbin/dpkg-reconfigure tzdata

and then select "None of the above". This will give you a list of
GMT-based timezones as well as UTC. (If you care about the difference
between them, or TAI and the business of leap seconds, then you've
more reading to do.)

The debian-installer tries to keep things a little simpler, and guide
the majority of people towards typical choices.

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.)

Cheers,
David.

Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

Greg Wooledge
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.

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.

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.

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.

I don't have any kind of statistics for how many programs use one vs.
the other.  It's not trivial to find out.

Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

tomas@tuxteam.de
On Mon, Aug 12, 2019 at 08:38:47AM -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.
>
> 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.
FWIW, I see /etc/timezone mentioned in the libc docs, whereas
I can't find /etc/timezone there.

So I'd guess /etc/timezone to be the relevant one for libc
(but there might be other important subsystems). Apt doesn't
say anything (I'd expect that -- those two files are more
typically taken care of in some post-install).

This all is from a very cursory glance, so take it with the
appropriate fist of salt.

Cheers
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: buster netinst timezone

andreimpopescu
In reply to this post by Greg Wooledge
On Lu, 12 aug 19, 08:38:47, Greg Wooledge wrote:
>
> I don't have any kind of statistics for how many programs use one vs.
> the other.  It's not trivial to find out.
 
/etc/localtime gets many more hits on https://codesearch.debian.net, if
you consider this to be a relevant metric.

FWIW, according to some source code comments there is no standard, not
even across Linux distributions, so many programs check both (and some
others not existing on Debian).

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

signature.asc (849 bytes) Download Attachment
12