Ed Greshko writes:
On 22/03/2021 19:26, Patrick O'Callaghan wrote:
> On Sun, 2021-03-21 at 19:48 -0400, Sam Varshavchik wrote:
>> But, it seems that this was too simple. Things cannot be this simple
>> anymore. We must have daemons involved in this process, for some
>> unclear
>> reason. The more, the merrier.
> Pandemonium.
>
Even though these comments are not germane to the subject it should be
pointed out that the
command "timedatectl" does more than just set the timezone. It does unify,
or seeks to unify,
aspects of setting the time and date.
What's there beyond a single setting, somewhere, that designates the
system's time zone, that's not clear to me. It all boils down to a single
setting, somewhere.
And just having a single file with the setting is the most simple, basic,
approach that could possibly be. Well, I do see an argument for a
configuration file, somewhere, with a larger scope and the timezone is one
configuration setting in there. That also seems reasonable to me.
But now there's an entire executable. That apparently talks to some daemon
somewhere. And, the end result is a complicated process that shouldn't be
more involved than just saving the setting somewhere.
It's going to be pretty hard to have
echo Asia/Taipei >/etc/timezone
result in a system hanging.
An example of that is that the user need not know what process is
being used
for NTP service.
The set-ntp takes care of that.
I'm not sure why NTP has to be involved in any of this. NTP counts seconds.
The timezone setting determines how this single counter translates into wall
time. I don't see how changing the system's timezone would have any effect
on ntp.
When it comes to time zones, it can help clear up some ambiguities
for
people that don't live in
the US. Like, did you know that Taiwan the abbreviation for our time zone
is CST? Setting the
time zone from the list provided by --list-timezones can assist those
unaware of such things.
I suppose it never occured to anyone to have that list kept in a plain text
file somewhere.
I can see the merit of using a command to the timezone if all it did was
check the given timezone against the list stored in such a configuration
file, and then update /etc/timezone if the timezone setting is valid.
I take it that it's still unknown what's causing this hang. I don't think it
matters. The real bug is having this rube-goldbergian contraption in the
first place. Just for setting a time zone.
This is complexity purely for the sake of having complexity, and introducing
more unneeded dependencies on the systemd monstrosity.