Re: tzdata-legacy [was: Re: systemd and timezone]

[David Wright]

On Sat 06 Jan 2024 at 02:57:53 (-0600), Nate Bargmann wrote:
> * On 2024 06 Jan 01:00 -0600, Max Nikulin wrote:
> > US/Eastern & Co has been moved to tzdata-legacy as well. Currently used
> > identifiers are based on cities: America/New_York.
> 
> Ugghhh!
> 
> I guess I'll be going to the legacy package then until
> $WHOEVER_IS_IN_CHARGE issues a decree that it too shall be eliminated.
> I really don't get the fascination with some city hundreds of miles
> distant defining the time zone.

Until fairly recently there wasn't a $WHOEVER_IS_IN_CHARGE to issue
the decree as Congress now does. A lot of the rules were made locally.

> Why Chicago for US/Central?  There are
> any number of cities in US/Central that could be referenced, but no,
> pick the most notorious one--rolls eyes.

I don't know what your problem is with Chicago: it's merely the
largest city in the area covered by the timezone.

> I could even accept America/Central without complaint.  Yeah, US is a
> directory and Central is a symlink to ../America/Chicago that could be
> manually added to a system if need be.

States still have the right to decide whether to observe DST, just
so long as any clock changes occur at the same time as everybody
else. So it's conceivable that Texas could, for example, decide
changing clocks is a waste of effort, and stay on one or the other
all year. In which case, it's a simple matter to cater for that
with the addition of an America/Houston timezone.

Impossible to do that with America/Central; I think it's long overdue
to recognise these old names as a legacy of earlier attempts to
specify time zones. Historically, some of them (like Eastern) don't
work anyway. Also it's doubly unfortunate, for non-Americans, that
there's a region of the world called Central America.

> Ambles off shaking fist at a cloud...

Cheers,
David.

manpages package [WAS Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

[Andrew M.A. Cater]

On Sat, Jan 06, 2024 at 01:17:13PM -0600, John Hasler wrote:
> Try manpages.org .
> -- 
> John Hasler 
> j...@sugarbit.com
> Elmwood, WI USA
>

If you're on a Debian system, this should already be installed but otherwise

apt-get install manpages

Also - manpages.debian.org gives you a searchable interface to all the
Debian manpages.

All the best

Andy
(amaca...@debian.org)
 

Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

[gene heskett]

On 1/6/24 12:07, Max Nikulin wrote:

On 06/01/2024 18:40, gene heskett wrote:
Put all system clocks on UTC, and then /etc/timezone is the actual 
string specifying the local offset. No doubt some user confusion, but 
overall a lot simpler.


I still do not see any connection with splitting a part of files and 
links into another package tzdata-legacy. Kernel anyway keeps time in 
UTC, RTC nowadays is mostly in UTC as well.


Notice that /etc/timezone is a legacy Debian-specific way, most of 
applications use the /etc/localtime symlink.


I do not think there are strong reasons for tzdata-legacy, but I do not 
see a reason for rant as well.


Or, if someone know how to make systemd's timesyncd actually work, 
I've not been able to do that on 7 machines here, that would be 
appreciated too.  Lack of documentation (man pages) for that puppy is 
a major blockaid here on bookworm.


Even if you do not use search engines for some reason, have you tried to 
ask at least systemd itself?


     systemctl help systemd-timesyncd


Does not exist as I manually deleted it and installed ntpsec when I 
could not find any docs to help make it work.  I needed a timeserver 
that did not depend on debians pool and ntpsec answered the call.
I set it up as a stratum 2 server, referencing the debian pool and just 
now got done re-configuring ntp.conf on the rest of my machines that are 
currently booted, to use this machine as a server.


If debian is going to supply systemd's timesyncd as a client, I expected 
a bookworm install to just work. It did not and without docs I have to 
pester the list, which has gotten me a bad rep because the lack of docs 
for this stuff has me in a screw google frame of mind by the time I get 
around to asking the list.  Lately, everytime I go anywhere near google 
or a gmail link I get attacked by a virus that calls itself norton 
antivirus. That is an oxymoron, like military intelligence.



.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

[John Hasler]

Try manpages.org .
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

[gene heskett]

On 1/6/24 09:25, John Hasler wrote:

The documentation for Chrony is:

chrony.conf (5)  - chronyd configuration file
chronyc (1)  - command-line interface for chrony daemon
chronyd (8)  - chrony daemon

Also see /usr/share/doc/chrony .

Don't use "pool" to sync to a single source.  Use  "server".
does this also work for ntpsec?  Yes it does, thank you for the hint, 
John. now that printer is hitting only my server instead of pestering 
the debian pool.


man chrony.conf


is on the missing list for armbian buster, John. And is not debians 
problem. Which is what is running this 3d printer. Do you know the name 
of the man page package that would install those man pages?  chrony 
isn't the only man pages missing.







Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

[Max Nikulin]

On 06/01/2024 18:40, gene heskett wrote:
Put all system clocks on UTC, and then /etc/timezone is the actual 
string specifying the local offset. No doubt some user confusion, but 
overall a lot simpler.


I still do not see any connection with splitting a part of files and 
links into another package tzdata-legacy. Kernel anyway keeps time in 
UTC, RTC nowadays is mostly in UTC as well.


Notice that /etc/timezone is a legacy Debian-specific way, most of 
applications use the /etc/localtime symlink.


I do not think there are strong reasons for tzdata-legacy, but I do not 
see a reason for rant as well.


Or, if someone know how to make systemd's timesyncd actually work, I've 
not been able to do that on 7 machines here, that would be appreciated 
too.  Lack of documentation (man pages) for that puppy is a major 
blockaid here on bookworm.


Even if you do not use search engines for some reason, have you tried to 
ask at least systemd itself?


systemctl help systemd-timesyncd

Re: tzdata-legacy [was: Re: systemd and timezone]

[Greg Wooledge]

On Sat, Jan 06, 2024 at 02:57:53AM -0600, Nate Bargmann wrote:
> I really don't get the fascination with some city hundreds of miles
> distant defining the time zone.  Why Chicago for US/Central?  There are
> any number of cities in US/Central that could be referenced, but no,
> pick the most notorious one--rolls eyes.

 is the only page I've
ever found that EXPLAINS things properly.  I strongly recommend it.

Among other things, it says:

 * Use the most populous among locations in a region, e.g., prefer
   Asia/Shanghai to Asia/Beijing. Among locations with similar populations,
   pick the best-known location, e.g., prefer Europe/Rome to Europe/Milan.

So, it's based on population and fame.

Re: was: Re: tzdata-legacy [was: Re: systemd and timezone]

[John Hasler]

The documentation for Chrony is:

chrony.conf (5)  - chronyd configuration file
chronyc (1)  - command-line interface for chrony daemon
chronyd (8)  - chrony daemon

Also see /usr/share/doc/chrony .

Don't use "pool" to sync to a single source.  Use  "server".

man chrony.conf


-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: tzdata-legacy [was: Re: systemd and timezone]

[gene heskett]

On 1/6/24 04:15, Nate Bargmann wrote:

* On 2024 06 Jan 01:00 -0600, Max Nikulin wrote:

US/Eastern & Co has been moved to tzdata-legacy as well. Currently used
identifiers are based on cities: America/New_York.


Ugghhh!

I guess I'll be going to the legacy package then until
$WHOEVER_IS_IN_CHARGE issues a decree that it too shall be eliminated.
I really don't get the fascination with some city hundreds of miles
distant defining the time zone.  Why Chicago for US/Central?  There are
any number of cities in US/Central that could be referenced, but no,
pick the most notorious one--rolls eyes.

I could even accept America/Central without complaint.  Yeah, US is a
directory and Central is a symlink to ../America/Chicago that could be
manually added to a system if need be.

Ambles off shaking fist at a cloud...

You got company on that trail.


- Nate



Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

was: Re: tzdata-legacy [was: Re: systemd and timezone]

[gene heskett]

On 1/6/24 01:18, Max Nikulin wrote:

On 06/01/2024 12:18, gene heskett wrote:

On 1/5/24 23:29, Greg Wooledge wrote:

On Fri, Jan 05, 2024 at 09:01:29PM -0500, Charles Kroeger wrote:

tzdata (2023d-1) unstable; urgency=medium

 upstream backward file) were moved to tzdata-legacy. This 
includes the



What's wrong with NTP, too simple?


NTP and tzdata have nothing to do with each other.


I see no relation to NTP as well. Somebody decided that 
/usr/share/zoneinfo is full of garbage and needs clean up:


https://lists.ubuntu.com/archives/ubuntu-devel/2023-January/042405.html

Some people prefer to not have tzdata at all:

https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata

I do not live in one of those special locations so I assume it won't 
affect me, but there is a small percentage here and in many other 
country's that live in locations that don't follow DST for some reason. 


DST is unrelated as well.

The change affects those who rely on POSIX-like EST5EDT timezones or on 
obsolete ones like Europe/Kyiv (recently renamed from Europe/Kiev). 
Those who provides various calendar services have significant 
probability to face user issues.


Doesn't this change affect trixie while bookworm will stick to current 
package style?



.
Well, since /usr/share/zoneinfo/UTC is a link to 
/usr/share/zoneinfo/Etc/UTC now, it would save about 4 megabytes worth 
of duplicates and links that is an organizational mess for the 
maintainer now. On the face of it. 25 years overdue? Put all system 
clocks on UTC, and then /etc/timezone is the actual string specifying 
the local offset. No doubt some user confusion, but overall a lot simpler.


Related subject:
Since I have several machines on my local network here, I've just been 
thru hell trying to get them all on the same page, and with debian 
version of ntpsec being happy with a single pool entry pointing to the 
ntpsec on this machine, it foiled my plans to reduce the load on the 
debian server pool by making this machine a stratum 2 server as some, 
not all, of the armbian boxes fail to sync at all with only one pool entry.


Or I'm still doing it wrong, always a possibility. If someone knows how 
to reliably sync to a single pool entry, I'm all ears.


Or, if someone know how to make systemd's timesyncd actually work, I've 
not been able to do that on 7 machines here, that would be appreciated 
too.  Lack of documentation (man pages) for that puppy is a major 
blockaid here on bookworm.  To me, its a potential solution in search of 
a problem that with chrony or ntpsec working, doesn't exist. chrony also 
claims to be an ntp server lookalike, again lack of docs to make it work 
are the problem. If docs on chrony exist, where the heck are they?  And 
what file utility do we have to read them with that actually works?.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: tzdata-legacy [was: Re: systemd and timezone]

[Nate Bargmann]

* On 2024 06 Jan 01:00 -0600, Max Nikulin wrote:
> US/Eastern & Co has been moved to tzdata-legacy as well. Currently used
> identifiers are based on cities: America/New_York.

Ugghhh!

I guess I'll be going to the legacy package then until
$WHOEVER_IS_IN_CHARGE issues a decree that it too shall be eliminated.
I really don't get the fascination with some city hundreds of miles
distant defining the time zone.  Why Chicago for US/Central?  There are
any number of cities in US/Central that could be referenced, but no,
pick the most notorious one--rolls eyes.

I could even accept America/Central without complaint.  Yeah, US is a
directory and Central is a symlink to ../America/Chicago that could be
manually added to a system if need be.

Ambles off shaking fist at a cloud...

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: tzdata-legacy [was: Re: systemd and timezone]

[Max Nikulin]

On 06/01/2024 13:02, Max Nikulin wrote:
The change affects those who rely on POSIX-like EST5EDT timezones or on 
obsolete ones like Europe/Kyiv (recently renamed from Europe/Kiev). 


Europe/Kiev (moved to tzdata-legacy) was renamed to Europe/Kyiv. Sorry 
for confusion.


US/Eastern & Co has been moved to tzdata-legacy as well. Currently used 
identifiers are based on cities: America/New_York.

tzdata-legacy [was: Re: systemd and timezone]

[Max Nikulin]

On 06/01/2024 12:18, gene heskett wrote:

On 1/5/24 23:29, Greg Wooledge wrote:

On Fri, Jan 05, 2024 at 09:01:29PM -0500, Charles Kroeger wrote:

tzdata (2023d-1) unstable; urgency=medium

 upstream backward file) were moved to tzdata-legacy. This includes the



What's wrong with NTP, too simple?


NTP and tzdata have nothing to do with each other.


I see no relation to NTP as well. Somebody decided that 
/usr/share/zoneinfo is full of garbage and needs clean up:


https://lists.ubuntu.com/archives/ubuntu-devel/2023-January/042405.html

Some people prefer to not have tzdata at all:

https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata

I do not live in one of those special locations so I assume it won't 
affect me, but there is a small percentage here and in many other 
country's that live in locations that don't follow DST for some reason. 


DST is unrelated as well.

The change affects those who rely on POSIX-like EST5EDT timezones or on 
obsolete ones like Europe/Kyiv (recently renamed from Europe/Kiev). 
Those who provides various calendar services have significant 
probability to face user issues.


Doesn't this change affect trixie while bookworm will stick to current 
package style?

Re: systemd and timezone

[gene heskett]

On 1/5/24 23:29, Greg Wooledge wrote:

On Fri, Jan 05, 2024 at 09:01:29PM -0500, Charles Kroeger wrote:

tzdata (2023d-1) unstable; urgency=medium

 From 2023c-8 on the tzdata package ships only timezones that follow the
 current rules of geographical region (continent or ocean) and city name.
 All legacy timezone symlinks (old or merged timezones mentioned in the
 upstream backward file) were moved to tzdata-legacy. This includes the
 US/* timezones.


Wow.  I am not a fan of that change.  It's good to have advance warning
that it's coming, though.


What's wrong with NTP, too simple?


NTP and tzdata have nothing to do with each other.  NTP keeps your system
clock in sync with sources across a network.  tzdata allows conversion
of the system clock into local time representation strings.


This separation of function may need to be repeated several times, Greg.

I do not live in one of those special locations so I assume it won't 
affect me, but there is a small percentage here and in many other 
country's that live in locations that don't follow DST for some reason. 
Those that are affected, could numerically generate considerable traffic 
here.


The maintainer of tzdata is not a job with thank you's but it should be.

.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: systemd and timezone

[Greg Wooledge]

On Fri, Jan 05, 2024 at 09:01:29PM -0500, Charles Kroeger wrote:
> tzdata (2023d-1) unstable; urgency=medium
> 
> From 2023c-8 on the tzdata package ships only timezones that follow the
> current rules of geographical region (continent or ocean) and city name.
> All legacy timezone symlinks (old or merged timezones mentioned in the
> upstream backward file) were moved to tzdata-legacy. This includes the
> US/* timezones.

Wow.  I am not a fan of that change.  It's good to have advance warning
that it's coming, though.

> What's wrong with NTP, too simple?

NTP and tzdata have nothing to do with each other.  NTP keeps your system
clock in sync with sources across a network.  tzdata allows conversion
of the system clock into local time representation strings.

Re: systemd and timezone

[Charles Kroeger]

apt-listchanges: News
-

tzdata (2023d-1) unstable; urgency=medium

From 2023c-8 on the tzdata package ships only timezones that follow the
current rules of geographical region (continent or ocean) and city name.
All legacy timezone symlinks (old or merged timezones mentioned in the
upstream backward file) were moved to tzdata-legacy. This includes the
US/* timezones.

Please install tzdata-legacy in case you need the legacy timezones or to
restore the previous behavior. This might be needed in case the system
provides timezone-aware data over the network (e. g. SQL databases).

 -- Benjamin Drung   Tue, 02 Jan 2024 14:17:33 +0100


What's wrong with NTP, too simple?

# dpkg-reconfigure tzdata

Current default time zone: 'America/New_York'
Local time is now:  Fri Jan  5 20:58:45 EST 2024.
Universal Time is now:  Sat Jan  6 01:58:45 UTC 2024.

-- 

System Information
GTK 3.24.39 / GLib 2.78.3
Locale: en_US.UTF-8 (charset: UTF-8)
Operating System: Linux 6.6.9-amd64 (x86_64)

Re: mktime (was: Re: systemd and timezone)

[tomas]

On Sat, Dec 23, 2023 at 01:09:02PM -0500, Jeffrey Walton wrote:

[...]

> On Sat, Dec 23, 2023 at 11:56 AM Max Nikulin  wrote:
> Here's what someone on the libc mailing list suggested:

[...]

> The person also suggested using Gnulib. My project was not using
> Gnulib, so it was not an option.

Thanks for the gnulib pointer. This way I "discovered" the _rz variants
(which gnulib provides, and which seem to be at home somewhere in _BSD
land).

Back when I did more C, I'd loved to have that. I always have seen gnulib
as "you need that whenever you're a poor sod on Windows". Learnt something
new :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: mktime (was: Re: systemd and timezone)

[Jeffrey Walton]

On Sat, Dec 23, 2023 at 11:56 AM Max Nikulin  wrote:
>
> On 23/12/2023 02:41, Jeffrey Walton wrote:
> > I've found lack of per-thread timezones and libc's inability to
> > convert time between timezones a bigger problem than other issues,
> > like explicitly setting a timezone for a process.
>
>  From my point of view the TZ environment variable makes timezone
> conversion a rather expensive operation. Some libc limitations are
> highlighted in
> https://data.iana.org/time-zones/theory.html#POSIX
>
> > The use case is, an appointment needs to be added to a database with
> > UTC time, but the sender of the appointment uses localtime+timezone
> > offset, like 1:00 PM PST or 1:00 PM EST. Trying to convert the
> > localtime+timezone time to UTC (or other timezone) on a server in a
> > thread is a real nightmare. Also see
> > .
>
>  From that message:
> >   * given: '15 Jan 2021 01:24:55 -0800 (PST)
>
> Time zone offset is given, so the timestamp can be unambiguously
> converted to UTC or seconds since epoch.
>
> If the DB is Postgres then I would delegate timezone-related
> computations to it.
>
> Posting code that can not be compiled may hide real issue.
>
> A couple of issues that may lead to undefined behavior:
>
> (info "(libc) Low-Level Time String Parsing")
> https://www.gnu.org/software/libc/manual/html_node/Low_002dLevel-Time-String-Parsing.html#index-strptime
> >• Before calling the ‘strptime’ function for a new input string, you
> >  should prepare the TM structure you pass.  Normally this will mean
> >  initializing all values to zero.  Alternatively, you can set all
> >  fields to values like ‘INT_MAX’, allowing you to determine which
> >  elements were set by the function call.  Zero does not work here
> >  since it is a valid value for many of the fields.
>
> Before calling mktime set tm_isdst to negative value if you do not know
> if DST is effective that moment.
>
> However being aware of tm_gmtoff GNU extension, I was not expected the
> following:
>
> (info "(libc) Broken-down Time")
> https://www.gnu.org/software/libc/manual/html_node/Broken_002ddown-Time.html#index-mktime
> >  The ‘mktime’ function ignores the specified contents of the
> >  ‘tm_wday’, ‘tm_yday’, ‘tm_gmtoff’, and ‘tm_zone’ members of the
> >  broken-down time structure.  It uses the values of the other
> >  components to determine the calendar time; it’s permissible for
> >  these components to have unnormalized values outside their normal
> >  ranges.  The last thing that ‘mktime’ does is adjust the components
> >  of the BROKENTIME structure, including the members that were
> >  initially ignored.
>
> So before calling mktime you need to set a timezone having offset of
> -0800. I have not figured out if the following approach may give
> incorrect results for some corner cases:
>
> - save tm_gmtoff from strptime results
> - set UTC timezone
> - call mktime
> - adjust result by saved tm_gmtoff
>
> Besides performance penalty due to tzset() I would not call it "nightmare".
>
> Beware with real timezones having DST or other time transitions. GNU
> libc implementation of mktime may give different results for the same
> passed argument depending of argument used for previous call.
>
> I would consider using some other library instead of libc:
> - std::chrono (I have heard of other C++ libraries created before chrono
> was added to the standard)
> - Qt
> - timelib C library from PHP
>
> P.S.
> https://stackoverflow.com/questions/11004273/what-is-stdpromise
> > std::broken_promise is the best named identifier in the standard
> > library. And there is no std::atomic_future.
> >  – Cubbi Jun 12, 2012 at 22:26
> struct tm is referred to as "Broken-down" time

Here's what someone on the libc mailing list suggested:
.
I'm not sure why threading broke in Mailman, so the thread could not
be followed. I should have posted it with the original email I sent.

The person offered some sample code, and stated there's no way to
avoid the [thread-unsafe] putenv with TZ. Also note that it does not
handle a source timezone string like '15 Jan 2021 01:24:55 -0800
(PST)'. You have to manually set TZ=America/California [?] first. It
is not clear to me why the part of the timezone string "-0800 (PST)"
is discarded when creating the time structure.

The person also suggested using Gnulib. My project was not using
Gnulib, so it was not an option.

I think what C programmers need is a libtz that works as expected. And
it needs to behave exactly like libc so there are no hard to track
down bugs.

Jeff

mktime (was: Re: systemd and timezone)

[Max Nikulin]

On 23/12/2023 02:41, Jeffrey Walton wrote:

I've found lack of per-thread timezones and libc's inability to
convert time between timezones a bigger problem than other issues,
like explicitly setting a timezone for a process.


From my point of view the TZ environment variable makes timezone 
conversion a rather expensive operation. Some libc limitations are 
highlighted in

https://data.iana.org/time-zones/theory.html#POSIX


The use case is, an appointment needs to be added to a database with
UTC time, but the sender of the appointment uses localtime+timezone
offset, like 1:00 PM PST or 1:00 PM EST. Trying to convert the
localtime+timezone time to UTC (or other timezone) on a server in a
thread is a real nightmare. Also see
.


From that message:

  * given: '15 Jan 2021 01:24:55 -0800 (PST)


Time zone offset is given, so the timestamp can be unambiguously 
converted to UTC or seconds since epoch.


If the DB is Postgres then I would delegate timezone-related 
computations to it.


Posting code that can not be compiled may hide real issue.

A couple of issues that may lead to undefined behavior:

(info "(libc) Low-Level Time String Parsing")
https://www.gnu.org/software/libc/manual/html_node/Low_002dLevel-Time-String-Parsing.html#index-strptime

   • Before calling the ‘strptime’ function for a new input string, you
 should prepare the TM structure you pass.  Normally this will mean
 initializing all values to zero.  Alternatively, you can set all
 fields to values like ‘INT_MAX’, allowing you to determine which
 elements were set by the function call.  Zero does not work here
 since it is a valid value for many of the fields.


Before calling mktime set tm_isdst to negative value if you do not know 
if DST is effective that moment.


However being aware of tm_gmtoff GNU extension, I was not expected the 
following:


(info "(libc) Broken-down Time")
https://www.gnu.org/software/libc/manual/html_node/Broken_002ddown-Time.html#index-mktime

 The ‘mktime’ function ignores the specified contents of the
 ‘tm_wday’, ‘tm_yday’, ‘tm_gmtoff’, and ‘tm_zone’ members of the
 broken-down time structure.  It uses the values of the other
 components to determine the calendar time; it’s permissible for
 these components to have unnormalized values outside their normal
 ranges.  The last thing that ‘mktime’ does is adjust the components
 of the BROKENTIME structure, including the members that were
 initially ignored.


So before calling mktime you need to set a timezone having offset of 
-0800. I have not figured out if the following approach may give 
incorrect results for some corner cases:


- save tm_gmtoff from strptime results
- set UTC timezone
- call mktime
- adjust result by saved tm_gmtoff

Besides performance penalty due to tzset() I would not call it "nightmare".

Beware with real timezones having DST or other time transitions. GNU 
libc implementation of mktime may give different results for the same 
passed argument depending of argument used for previous call.


I would consider using some other library instead of libc:
- std::chrono (I have heard of other C++ libraries created before chrono 
was added to the standard)

- Qt
- timelib C library from PHP

P.S.
https://stackoverflow.com/questions/11004273/what-is-stdpromise

std::broken_promise is the best named identifier in the standard
library. And there is no std::atomic_future.
 – Cubbi Jun 12, 2012 at 22:26

struct tm is referred to as "Broken-down" time

Re: systemd and timezone

[Pocket]

On 12/23/23 01:00, David Wright wrote:

On Fri 22 Dec 2023 at 18:52:09 (-0500), Pocket wrote:

On 12/22/23 18:04, David Wright wrote:

On Fri 22 Dec 2023 at 16:16:07 (-0500), Greg Wooledge wrote:

On Fri, Dec 22, 2023 at 08:59:42PM +0100, Sven Joachim wrote:

1. https://bugs.debian.org/803144
2. https://bugs.debian.org/346342

Wow, OK.  Fascinating historical context in there.

I've updated .  I believe it's
correct now, for both current and historic systems, although I can't
swear to the pre-Etch stuff.

Another bug at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726256

* copy /etc/localtime instead of symlinking (Closes: #726256)


 From the email I got from Lennart

CHANGES WITH 255:

     Announcements of Future Feature Removals and Incompatible Changes:

     * Support for split-usr (/usr/ mounted separately during late boot,
   instead of being mounted by the initrd before switching to
the rootfs)
   and unmerged-usr (parallel directories /bin/ and /usr/bin/,
/lib/ and
   /usr/lib/, …) has been removed. For more details, see:
https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html


     * Support for System V service scripts is now deprecated and
will be
   removed in a future release. Please make sure to update your
software
   *now* to include a native systemd unit file instead of a legacy
   System V script to retain compatibility with future systemd
releases.

So that bug is m[oot]


It's not the bug, but changes in /etc/localtime that are the concern
of this thread, ± side-effects on the importance of /etc/timezone.
It appears that Debian has switched between /etc/localtime being
a regular file and a symlink several times.

BTW, I think Debian is somewhat behind Lennart, as even bookworm
is AFAIK only up to 252. As for SysV, my bullseye has 39 scripts
in /etc/init.d/, and there are still plenty with bookworm.

Cheers,
David.




My point is that systemd will not support a split /usr.
Also /etc/localtime should be a symlink as per the standard.
The "dangling  symlink" in the bug report shouldn't ot isn't dangling.

It is a failure of debian, /usr/ not being mounted in the initrd.
That is what should/needs be fixed.

It also is quite meaningless that you have sysV scripts, They are going 
to be NOT supported in the future. debian either has to keep systemd at 
an old version or remove the sysv scripts as they will no longer be 
supported.  There is really no choice in the matter.


I have spoken

Re: Support for SysV service scripts deprecated in systemd 255 (was: systemd and timezone)

[Felix Miata]

David Wright composed on 2023-12-23 00:00 (UTC-0600):

> On Fri 22 Dec 2023 at 18:52:09 (-0500), Pocket wrote:

>> From the email I got from Lennart

>> CHANGES WITH 255:

>>     Announcements of Future Feature Removals and Incompatible Changes:

>>     * Support for split-usr (/usr/ mounted separately during late boot,
>>   instead of being mounted by the initrd before switching to
>> the rootfs)
>>   and unmerged-usr (parallel directories /bin/ and /usr/bin/,
>> /lib/ and
>>   /usr/lib/, …) has been removed. For more details, see:
>> https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html


>>     * Support for System V service scripts is now deprecated and
>> will be
>>   removed in a future release. Please make sure to update your
>> software
>>   *now* to include a native systemd unit file instead of a legacy
>>   System V script to retain compatibility with future systemd
>> releases.

>> So that bug is m[oot]
...
> BTW, I think Debian is somewhat behind Lennart, as even bookworm
> is AFAIK only up to 252. As for SysV, my bullseye has 39 scripts
> in /etc/init.d/, and there are still plenty with bookworm.

I have 22 in Trixie. Aren't what are left there nothing but compat placements? I
renamed /etc/init.d/, then rebooted. All seems pretty close to normal:
# inxi -S
System:
  Host: gx78b Kernel: 6.5.0-5-amd64 arch: x86_64 bits: 64 Desktop: Trinity
Distro: Debian GNU/Linux trixie/sid
# dmesg | grep aile
# journalctl -b --no-hostname | grep aile
Dec 23 01:43:04 (udev-worker)[291]: sunrpc: Process '/sbin/sysctl -q --pattern
^sunrpc --system' failed with exit code 1.
Dec 23 01:43:04 (udev-worker)[286]: lockd: Process '/sbin/sysctl -q --pattern
^fs.nfs.n[sl]m --system' failed with exit code 1.
Dec 23 01:43:04 (udev-worker)[286]: sunrpc: Process '/sbin/sysctl -q --pattern
^sunrpc --system' failed with exit code 1.
Dec 23 01:43:04 (udev-worker)[285]: lockd: Process '/sbin/sysctl -q --pattern
^fs.nfs.n[sl]m --system' failed with exit code 1.
Dec 23 01:43:06 blkmapd[525]: open pipe file /run/rpc_pipefs/nfs/blocklayout
failed: No such file or directory
Dec 23 01:43:06 rpc.mountd[538]: Failed to create listener xprt (mountd, 1, 
udp6)
Dec 23 01:43:06 rpc.mountd[538]: Failed to create listener xprt (mountd, 1, 
tcp6)
Dec 23 01:43:06 rpc.mountd[538]: Failed to create listener xprt (mountd, 2, 
udp6)
Dec 23 01:43:06 rpc.mountd[538]: Failed to create listener xprt (mountd, 2, 
tcp6)
Dec 23 01:43:06 rpc.mountd[538]: Failed to create listener xprt (mountd, 3, 
udp6)
Dec 23 01:43:06 rpc.mountd[538]: Failed to create listener xprt (mountd, 3, 
tcp6)
Dec 23 01:43:06 rpc.statd[565]: Failed to create listener xprt (statd, 1, udp6)
Dec 23 01:43:06 rpc.statd[565]: Failed to create listener xprt (statd, 1, tcp6)
Dec 23 01:43:16 systemd[787]: Dependency failed for filter-chain.service -
PipeWire filter chain daemon.
Dec 23 01:43:16 systemd[787]: filter-chain.service: Job 
filter-chain.service/start
failed with result 'dependency'.
Dec 23 01:43:16 systemd[787]: Dependency failed for wireplumber.service -
Multimedia Service Session Manager.
Dec 23 01:43:16 systemd[787]: wireplumber.service: Job wireplumber.service/start
failed with result 'dependency'.
#
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: systemd and timezone

[David Wright]

On Fri 22 Dec 2023 at 18:52:09 (-0500), Pocket wrote:
> On 12/22/23 18:04, David Wright wrote:
> > On Fri 22 Dec 2023 at 16:16:07 (-0500), Greg Wooledge wrote:
> > > On Fri, Dec 22, 2023 at 08:59:42PM +0100, Sven Joachim wrote:
> > > > 1. https://bugs.debian.org/803144
> > > > 2. https://bugs.debian.org/346342
> > > Wow, OK.  Fascinating historical context in there.
> > > 
> > > I've updated .  I believe it's
> > > correct now, for both current and historic systems, although I can't
> > > swear to the pre-Etch stuff.
> > Another bug at:
> > 
> >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726256
> > 
> > * copy /etc/localtime instead of symlinking (Closes: #726256)
> > 
> From the email I got from Lennart
> 
> CHANGES WITH 255:
> 
>     Announcements of Future Feature Removals and Incompatible Changes:
> 
>     * Support for split-usr (/usr/ mounted separately during late boot,
>   instead of being mounted by the initrd before switching to
> the rootfs)
>   and unmerged-usr (parallel directories /bin/ and /usr/bin/,
> /lib/ and
>   /usr/lib/, …) has been removed. For more details, see:
> https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html
> 
> 
>     * Support for System V service scripts is now deprecated and
> will be
>   removed in a future release. Please make sure to update your
> software
>   *now* to include a native systemd unit file instead of a legacy
>   System V script to retain compatibility with future systemd
> releases.
> 
> So that bug is m[oot]

It's not the bug, but changes in /etc/localtime that are the concern
of this thread, ± side-effects on the importance of /etc/timezone.
It appears that Debian has switched between /etc/localtime being
a regular file and a symlink several times.

BTW, I think Debian is somewhat behind Lennart, as even bookworm
is AFAIK only up to 252. As for SysV, my bullseye has 39 scripts
in /etc/init.d/, and there are still plenty with bookworm.

Cheers,
David.

Re: systemd and timezone

[David Wright]

On Fri 22 Dec 2023 at 14:54:13 (-0500), Greg Wooledge wrote:
> On Fri, Dec 22, 2023 at 01:29:09PM -0600, David Wright wrote:
> > With the proviso that I don't know what "restorecon" does in
> > postinst scripts, this list of .debs has been prefixed by
> > c for copy and l for link:
> > 
> >   l-tzdata_2007b-1_all.deb
> >   l-tzdata_2008e-1etch3_all.deb
> >   c-tzdata_2011k-0lenny1_all.deb
> >   c-tzdata_2014e-0squeeze1_all.deb
> >   c-tzdata_2015c-1_all.deb
> >   c-tzdata_2015g-0+deb6u1_all.deb
> >   c-tzdata_2016d-0+deb7u1_all.deb
> >   c-tzdata_2018e-0+deb8u1_all.deb
> >   l-tzdata_2020a-0+deb9u1_all.deb
> >   l-tzdata_2021a-1+deb11u10_all.deb
> >   l-tzdata_2021a-1+deb11u11_all.deb
> 
> Now I'm even more confused than before.  I thought Etch did "copy",
> but this list claims 20083-1etch3 did a link.  Did the behavior
> originally start out as link, then change to copy somewhere in the
> middle of Etch's lifespan, then change back to link for Debian 9?

So am I. The list above is deduced from the postinsts, and it seems
that for these two:

  x-tzdata_2007b-1_all.deb
  x-tzdata_2008e-1etch3_all.deb

there are both possibilities depending on which parts get executed.
So I'd run your eyes over those scripts yourself.

I've looked at the older packages, and these appear to be:

  l-timezone-7.48-3.deb
  l-timezone_7.55-2.deb
  c-timezones_2.0.7t-1.deb
  l-timezones_2.0.7.19981211-6.deb
  l-libc6_2.1.3-20.deb
  l-libc6_2.2.5-11.8_i386.deb
  l-libc6_2.3.2.ds1-22sarge6_i386.deb

Cheers,
David.

Re: systemd and timezone

[Greg Wooledge]

On Fri, Dec 22, 2023 at 06:36:55PM -0600, Nate Bargmann wrote:
> In Debian releases between Etch and Jessie (inclusive),

It's a wiki.  I assumed it would be clear in context, due to the
paragraphs before and after it, but if you want to change the wording,
change it.

Re: systemd and timezone

[Nate Bargmann]

* On 2023 22 Dec 15:34 -0600, Greg Wooledge wrote:
> On Fri, Dec 22, 2023 at 08:59:42PM +0100, Sven Joachim wrote:
> > 1. https://bugs.debian.org/803144
> > 2. https://bugs.debian.org/346342
> 
> Wow, OK.  Fascinating historical context in there.
> 
> I've updated .  I believe it's
> correct now, for both current and historic systems, although I can't
> swear to the pre-Etch stuff.

At the risk of being a pedant.  I find the text of the paragraph that
begins:

In Debian releases between Etch and Jessie,

in the Check Configured Timezone section to be potentially confusing.
To me the word "between" often means a range that is exclusive of its
end points, e.g. "between the lines".

Would this be better worded as:

In Debian releases beginning with Etch and ending with Jessie,

or would:

In Debian releases between Etch and Jessie (inclusive),

be good enough?

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: systemd and timezone

[Pocket]

On 12/22/23 18:04, David Wright wrote:

On Fri 22 Dec 2023 at 16:16:07 (-0500), Greg Wooledge wrote:

On Fri, Dec 22, 2023 at 08:59:42PM +0100, Sven Joachim wrote:

1. https://bugs.debian.org/803144
2. https://bugs.debian.org/346342

Wow, OK.  Fascinating historical context in there.

I've updated .  I believe it's
correct now, for both current and historic systems, although I can't
swear to the pre-Etch stuff.

Another bug at:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726256

* copy /etc/localtime instead of symlinking (Closes: #726256)

Cheers,
David.


From the email I got from Lennart


CHANGES WITH 255:

    Announcements of Future Feature Removals and Incompatible Changes:

    * Support for split-usr (/usr/ mounted separately during late boot,
  instead of being mounted by the initrd before switching to 
the rootfs)
  and unmerged-usr (parallel directories /bin/ and /usr/bin/, 
/lib/ and

  /usr/lib/, …) has been removed. For more details, see:
https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html


    * Support for System V service scripts is now deprecated and 
will be
  removed in a future release. Please make sure to update your 
software

  *now* to include a native systemd unit file instead of a legacy
  System V script to retain compatibility with future systemd 
releases.



So that bug is mute



--
Hindi madali ang maging ako

Re: systemd and timezone

[Pocket]

On 12/22/23 18:04, David Wright wrote:

On Fri 22 Dec 2023 at 16:16:07 (-0500), Greg Wooledge wrote:

On Fri, Dec 22, 2023 at 08:59:42PM +0100, Sven Joachim wrote:

1. https://bugs.debian.org/803144
2. https://bugs.debian.org/346342

Wow, OK.  Fascinating historical context in there.

I've updated .  I believe it's
correct now, for both current and historic systems, although I can't
swear to the pre-Etch stuff.

Another bug at:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726256

* copy /etc/localtime instead of symlinking (Closes: #726256)

Cheers,
David.



Systemd no longer supports a split /usr



--
Hindi madali ang maging ako

Re: systemd and timezone

[David Wright]

On Fri 22 Dec 2023 at 16:16:07 (-0500), Greg Wooledge wrote:
> On Fri, Dec 22, 2023 at 08:59:42PM +0100, Sven Joachim wrote:
> > 1. https://bugs.debian.org/803144
> > 2. https://bugs.debian.org/346342
> 
> Wow, OK.  Fascinating historical context in there.
> 
> I've updated .  I believe it's
> correct now, for both current and historic systems, although I can't
> swear to the pre-Etch stuff.

Another bug at:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726256

* copy /etc/localtime instead of symlinking (Closes: #726256)

Cheers,
David.

Re: systemd and timezone

[Nicolas George]

Jeffrey Walton (12023-12-22):
> I've found lack of per-thread timezones and libc's inability to
> convert time between timezones a bigger problem than other issues,
> like explicitly setting a timezone for a process.

Unix API makes an habit of this kind of thing. Often, it is because the
feature was not designed from the start, and then it was shoehorned into
existing APIs with a global state, changing their behavior in a subtle
and dangerous manner.

Locales are one of the worst offenders. They are the reason you could
get, around the turn of the century, the interactive interpreter for the
OCaml language accept “let pi = 3.14;;” and output
“val pi : float = 3.”.

Yet, (some) localized functions now exist with a _l variant taking a
locale_t argument, but no such thing exists for timezone.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature

Re: systemd and timezone

[Greg Wooledge]

On Fri, Dec 22, 2023 at 08:59:42PM +0100, Sven Joachim wrote:
> 1. https://bugs.debian.org/803144
> 2. https://bugs.debian.org/346342

Wow, OK.  Fascinating historical context in there.

I've updated .  I believe it's
correct now, for both current and historic systems, although I can't
swear to the pre-Etch stuff.

Re: systemd and timezone

[Sven Joachim]

On 2023-12-22 11:11 -0500, Greg Wooledge wrote:

> On Fri, Dec 22, 2023 at 09:30:23AM -0600, David Wright wrote:
>>   https://wiki.debian.org/TimeZoneChanges
>>
>> still says:
>>
>>  "In Debian releases Etch and later, /etc/localtime is a copy of the
>>   original data file. Check the contents of /etc/timezone to see the
>>   name of the timezone. If the system is configured normally, you
>>   should find that the zoneinfo file referenced by this name is
>>   identical to /etc/localtime."
>
> I'd change it immediately, but I don't want to make a change that isn't
> correct.
>
> Was this paragraph actually correct for Etch?  Was /etc/localtime a
> literal *copy* of a file instead of symlink?

Yes.

> If so, when did it change?

In tzdata 2016a-1[1].

> Or, was this wrong for Etch, and /etc/localtime was always a symlink?

Initially /etc/localtime was a symlink, but in Etch it had been
converted to a file[2].

Cheers,
   Sven


1. https://bugs.debian.org/803144
2. https://bugs.debian.org/346342

Re: systemd and timezone

[Greg Wooledge]

On Fri, Dec 22, 2023 at 01:29:09PM -0600, David Wright wrote:
> With the proviso that I don't know what "restorecon" does in
> postinst scripts, this list of .debs has been prefixed by
> c for copy and l for link:
> 
>   l-tzdata_2007b-1_all.deb
>   l-tzdata_2008e-1etch3_all.deb
>   c-tzdata_2011k-0lenny1_all.deb
>   c-tzdata_2014e-0squeeze1_all.deb
>   c-tzdata_2015c-1_all.deb
>   c-tzdata_2015g-0+deb6u1_all.deb
>   c-tzdata_2016d-0+deb7u1_all.deb
>   c-tzdata_2018e-0+deb8u1_all.deb
>   l-tzdata_2020a-0+deb9u1_all.deb
>   l-tzdata_2021a-1+deb11u10_all.deb
>   l-tzdata_2021a-1+deb11u11_all.deb

Now I'm even more confused than before.  I thought Etch did "copy",
but this list claims 20083-1etch3 did a link.  Did the behavior
originally start out as link, then change to copy somewhere in the
middle of Etch's lifespan, then change back to link for Debian 9?

Also, I checked a Debian 7 system (it is indeed a copy) and a Debian 9
system (it's a link), which at least confirms two of the points on
this list.

Re: systemd and timezone

[Jeffrey Walton]

On Fri, Dec 22, 2023 at 8:33 AM  wrote:
>
> On Fri, Dec 22, 2023 at 07:26:37PM +0700, Max Nikulin wrote:
> >  [...]
> > /etc/localtime is a global setting. Its change may affect all users not
> > having explicit TZ. Something better than libc is required for an
> > application (especially multithread one) that need to deal with time in
> > multiple time zones.
>
> Yes. Libc's (POSIX, for that) interface is pretty bad. It effectively
> limits one to one time zone per libc instance.

I've found lack of per-thread timezones and libc's inability to
convert time between timezones a bigger problem than other issues,
like explicitly setting a timezone for a process.

The use case is, an appointment needs to be added to a database with
UTC time, but the sender of the appointment uses localtime+timezone
offset, like 1:00 PM PST or 1:00 PM EST. Trying to convert the
localtime+timezone time to UTC (or other timezone) on a server in a
thread is a real nightmare. Also see
.

Jeff

Re: systemd and timezone

[Greg Wooledge]

On Fri, Dec 22, 2023 at 07:56:56PM +0100, Arno Lehmann, ITS wrote:
> I have Etch running here, and the /etc/localtime file is not a symlink, nor
> a hardlink to a zone file:
> 
> TomBombadil:~# ls -lhi /etc/timezone /etc/localtime
> 159667 -rw-r--r-- 1 root root 842 2020-11-14 18:27 /etc/localtime
>140 -rw-r--r-- 1 root root  14 2020-11-14 18:27 /etc/timezone
> TomBombadil:~# ls -lhi /usr/share/zoneinfo/Europe/Berlin
> 186905 -rw-r--r-- 1 root root 842 2008-10-17 18:57
> /usr/share/zoneinfo/Europe/Berlin
> TomBombadil:~# diff -q /usr/share/zoneinfo/Europe/Berlin /etc/localtime ;
> echo $?
> 0
> TomBombadil:~# cat /etc/debian_version
> 4.0

Thanks.  Unfortunately, that means we have to track down *when*
it changed.  I'll get around to trying that at some point, perhaps.
Maybe start by reading all the release notes after Etch

Re: systemd and timezone

[David Wright]

On Fri 22 Dec 2023 at 11:11:18 (-0500), Greg Wooledge wrote:
> On Fri, Dec 22, 2023 at 09:30:23AM -0600, David Wright wrote:
> >   https://wiki.debian.org/TimeZoneChanges
> > 
> > still says:
> > 
> >  "In Debian releases Etch and later, /etc/localtime is a copy of the
> >   original data file. Check the contents of /etc/timezone to see the
> >   name of the timezone. If the system is configured normally, you
> >   should find that the zoneinfo file referenced by this name is
> >   identical to /etc/localtime."
> 
> I'd change it immediately, but I don't want to make a change that isn't
> correct.
> 
> Was this paragraph actually correct for Etch?  Was /etc/localtime a
> literal *copy* of a file instead of symlink?  If so, when did it change?
> 
> Or, was this wrong for Etch, and /etc/localtime was always a symlink?

With the proviso that I don't know what "restorecon" does in
postinst scripts, this list of .debs has been prefixed by
c for copy and l for link:

  l-tzdata_2007b-1_all.deb
  l-tzdata_2008e-1etch3_all.deb
  c-tzdata_2011k-0lenny1_all.deb
  c-tzdata_2014e-0squeeze1_all.deb
  c-tzdata_2015c-1_all.deb
  c-tzdata_2015g-0+deb6u1_all.deb
  c-tzdata_2016d-0+deb7u1_all.deb
  c-tzdata_2018e-0+deb8u1_all.deb
  l-tzdata_2020a-0+deb9u1_all.deb
  l-tzdata_2021a-1+deb11u10_all.deb
  l-tzdata_2021a-1+deb11u11_all.deb

Cheers,
David.

Re: systemd and timezone

[Arno Lehmann, ITS]

Hi Greg,

Am 22.12.2023 um 17:11 schrieb Greg Wooledge:

On Fri, Dec 22, 2023 at 09:30:23AM -0600, David Wright wrote:

   https://wiki.debian.org/TimeZoneChanges

still says:

  "In Debian releases Etch and later, /etc/localtime is a copy of the
   original data file. Check the contents of /etc/timezone to see the
   name of the timezone. If the system is configured normally, you
   should find that the zoneinfo file referenced by this name is
   identical to /etc/localtime."


I'd change it immediately, but I don't want to make a change that isn't
correct.

Was this paragraph actually correct for Etch?  Was /etc/localtime a
literal *copy* of a file instead of symlink?  If so, when did it change?

Or, was this wrong for Etch, and /etc/localtime was always a symlink?



I have Etch running here, and the /etc/localtime file is not a symlink, 
nor a hardlink to a zone file:


TomBombadil:~# ls -lhi /etc/timezone /etc/localtime
159667 -rw-r--r-- 1 root root 842 2020-11-14 18:27 /etc/localtime
   140 -rw-r--r-- 1 root root  14 2020-11-14 18:27 /etc/timezone
TomBombadil:~# ls -lhi /usr/share/zoneinfo/Europe/Berlin
186905 -rw-r--r-- 1 root root 842 2008-10-17 18:57 
/usr/share/zoneinfo/Europe/Berlin
TomBombadil:~# diff -q /usr/share/zoneinfo/Europe/Berlin /etc/localtime 
; echo $?

0
TomBombadil:~# cat /etc/debian_version
4.0

Cheers,

Arno

Re: systemd and timezone

[Greg Wooledge]

On Fri, Dec 22, 2023 at 09:30:23AM -0600, David Wright wrote:
>   https://wiki.debian.org/TimeZoneChanges
> 
> still says:
> 
>  "In Debian releases Etch and later, /etc/localtime is a copy of the
>   original data file. Check the contents of /etc/timezone to see the
>   name of the timezone. If the system is configured normally, you
>   should find that the zoneinfo file referenced by this name is
>   identical to /etc/localtime."

I'd change it immediately, but I don't want to make a change that isn't
correct.

Was this paragraph actually correct for Etch?  Was /etc/localtime a
literal *copy* of a file instead of symlink?  If so, when did it change?

Or, was this wrong for Etch, and /etc/localtime was always a symlink?

Re: systemd and timezone

[tomas]

On Fri, Dec 22, 2023 at 08:55:04AM -0500, Greg Wooledge wrote:
> On Fri, Dec 22, 2023 at 02:17:47PM +0100, to...@tuxteam.de wrote:
> > whereas /etc/timezone [1] is just the
> > global default for the (libc) applications to fall back to whenever they
> > don't have specified one.
> > 
> > [1] Or whatever that thing may be called in systemd-land.
> 
> Unless I'm gravely mistaken, /etc/localtime is the one that almost
> everything uses (libc and systemd)

This is also what the manuals for timezone(3) and tzset(3) would
suggest.
> and /etc/timezone is a legacy
> relic, which nobody's *supposed* to be using, but which some old
> applications may still use, so we can't just remove it.

I don't like to link to SO and its ilk (to me, they are enclosure [0]
devices, taking from the Commons for the profit of some), but this
ref here [1] has a useful and thorough description. The short version
is that you are basically right, Greg: /etc/localtime is the relevant
one for the current discussion, whereas /etc/timezone does have a
function under Debian (mostly at install time), but a different one.

Beyond our bubble there is some diversity (/etc/TZ, /etc/TIMEZONE),
and Java (surprised?) does its own thing.

Cheers

[0] https://en.wikipedia.org/wiki/Enclosure
[1] 
https://unix.stackexchange.com/questions/16241/debugging-java-program-for-changing-timezone-configuration-file-on-ubuntu
-- 
t


signature.asc
Description: PGP signature

Re: systemd and timezone

[David Wright]

On Fri 22 Dec 2023 at 08:55:04 (-0500), Greg Wooledge wrote:
> On Fri, Dec 22, 2023 at 02:17:47PM +0100, to...@tuxteam.de wrote:
> > whereas /etc/timezone [1] is just the
> > global default for the (libc) applications to fall back to whenever they
> > don't have specified one.
> > 
> > [1] Or whatever that thing may be called in systemd-land.
> 
> Unless I'm gravely mistaken, /etc/localtime is the one that almost
> everything uses (libc and systemd), and /etc/timezone is a legacy
> relic, which nobody's *supposed* to be using, but which some old
> applications may still use, so we can't just remove it.

I think you're right, just as you wrote on the Glorious Twelfth
in 2019, only expressing that distinction seemed to make some
people uncomfortable.

One problem that has occurred on and off is how you report what the
"system timezone" is set to. Yesterday Max posted:

 "That is why
readlink /etc/localtime
  or
ls -l /etc/localtime
  as a primary source."

But in the past, /etc/localtime wasn't a symlink, but a copy of
the appropriate zoneinfo file. So cat /etc/timezone was really
the only option, unless you wrote a script to look for where
/etc/localtime might have been copied from.

  https://wiki.debian.org/TimeZoneChanges

still says:

 "In Debian releases Etch and later, /etc/localtime is a copy of the
  original data file. Check the contents of /etc/timezone to see the
  name of the timezone. If the system is configured normally, you
  should find that the zoneinfo file referenced by this name is
  identical to /etc/localtime."

> dpkg-reconfigure tzdata updates both of them.
> timedatectl set-timezone only updates /etc/localtime.

which would imply that the concerns in:
  https://lists.debian.org/debian-user/2019/09/msg00035.html
are still relevant.

Cheers,
David.

Re: systemd and timezone

[Greg Wooledge]

On Fri, Dec 22, 2023 at 02:17:47PM +0100, to...@tuxteam.de wrote:
> whereas /etc/timezone [1] is just the
> global default for the (libc) applications to fall back to whenever they
> don't have specified one.
> 
> [1] Or whatever that thing may be called in systemd-land.

Unless I'm gravely mistaken, /etc/localtime is the one that almost
everything uses (libc and systemd), and /etc/timezone is a legacy
relic, which nobody's *supposed* to be using, but which some old
applications may still use, so we can't just remove it.

dpkg-reconfigure tzdata updates both of them.
timedatectl set-timezone only updates /etc/localtime.

Re: systemd and timezone

[tomas]

On Fri, Dec 22, 2023 at 07:26:37PM +0700, Max Nikulin wrote:
> On 21/12/2023 21:53, to...@tuxteam.de wrote:
> > On Thu, Dec 21, 2023 at 09:08:09AM -0500, Dan Ritter wrote:
> > > 
> > > And
> > > it is quite possible on a few of those machines to have multiple
> > > desktop users, each from a different TZ.
> > 
> > I've sometimes the impression that desktop environments are losing
> > the concept pf multi-user operating systems and are regreding to
> > something like Windows 95.
> 
> Tomas, I do not see you point and I feel like my messages may cause some
> sort of confusion.

I'm easily confused, that happens. So thanks for your patience :-)
In any case, no offense intended, and much less to you.

> POSIX and libc have some shortcomings, but they are not unique to desktop
> environments and applicable to window manager sessions and even to
> standalone applications.

I know.

> /etc/localtime is a global setting. Its change may affect all users not
> having explicit TZ. Something better than libc is required for an
> application (especially multithread one) that need to deal with time in
> multiple time zones.

Yes. Libc's (POSIX, for that) interface is pretty bad. It effectively
limits one to one time zone per libc instance.

> Systemd, from my point of view, does not make it worse. It just allows e.g.
> firefox to subscribe to timezone change events instead of adding explicit
> support of /etc/localtime and inotify handlers.

I think it's more a perception thing. People are tempted to believe "the
operating system has a timezone", whereas /etc/timezone [1] is just the
global default for the (libc) applications to fall back to whenever they
don't have specified one.

> I am in doubts if Linux ever was more "multiuser" in respect to timezones.

It is definitely more multiuser than the Windows95 it is trying to
emulate these days (yes, a bit of hyperbole, but hey).

Cheers

[1] Or whatever that thing may be called in systemd-land.
> 
> 


signature.asc
Description: PGP signature

Re: systemd and timezone

[Andy Smith]

Hello,

On Thu, Dec 21, 2023 at 06:36:34PM -0600, Nicholas Geovanis wrote:
> Servers work in groups and log-aggregation and analysis software is normal
> in that context. And since your web server fleet, for one example, may be
> spread across multiple timezones or multiple continents to reduce latency,
> you configure accordingly.

I am personally a believer in "all servers on UTC all the time;
largely single-user workstations can be user-decided" (just a
personal preference, let's not call each other wrong if we don't
agree with it). However, I was told once by a Google employee that
all of Google's servers use some US local time zone and that it was
largely considered a mistake. Make of that what you will!

Everywhere I've worked that had servers that weren't in UTC had
people expressing misgivings about that, whereas when they were in
UTC that was easier for people to understand.

At one place their servers were set to Europe/London and twice a
year we'd get a spate of support tickets from widely-dispersed users
asking why all the reports on the file servers had "gone
forward/back an hour" (largely non-technical users who just knew how
to use a graphical SCP client). But we never got approval to change
things to remain in UTC all year.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: systemd and timezone

[Max Nikulin]

On 21/12/2023 21:53, to...@tuxteam.de wrote:

On Thu, Dec 21, 2023 at 09:08:09AM -0500, Dan Ritter wrote:


And
it is quite possible on a few of those machines to have multiple
desktop users, each from a different TZ.


I've sometimes the impression that desktop environments are losing
the concept pf multi-user operating systems and are regreding to
something like Windows 95.


Tomas, I do not see you point and I feel like my messages may cause some 
sort of confusion.


POSIX and libc have some shortcomings, but they are not unique to 
desktop environments and applicable to window manager sessions and even 
to standalone applications.


/etc/localtime is a global setting. Its change may affect all users not 
having explicit TZ. Something better than libc is required for an 
application (especially multithread one) that need to deal with time in 
multiple time zones.


Systemd, from my point of view, does not make it worse. It just allows 
e.g. firefox to subscribe to timezone change events instead of adding 
explicit support of /etc/localtime and inotify handlers.


I am in doubts if Linux ever was more "multiuser" in respect to timezones.

Re: systemd and timezone

[Nicholas Geovanis]

On Thu, Dec 21, 2023, 10:06 AM Max Nikulin  wrote:

> On 21/12/2023 12:33, to...@tuxteam.de wrote:
> .
> >
> > Double ugh.
> >
> > UNIX got that right from the start. Now this crazy notion "the computer
> > HAS to have a timezone of its own" is creeping in.
>
> Even admins may wish to see local time, not UTC in logs. So the D-Bus
> interface is no worse than the /etc/localtime file.
>

Servers work in groups and log-aggregation and analysis software is normal
in that context. And since your web server fleet, for one example, may be
spread across multiple timezones or multiple continents to reduce latency,
you configure accordingly.

>

Re: systemd and timezone

[gene heskett]

On 12/21/23 16:54, Nicolas George wrote:

to...@tuxteam.de (12023-12-21):

I've sometimes the impression that desktop environments are losing
the concept pf multi-user operating systems and are regreding to
something like Windows 95.


Desktop environment and the “modern” applications designed for them had
already lost the ability to put back everything in place by quitting and
restarting. Now they are losing the concept of multiple users, and they
are also losing the ability to run several independent instances of the
same program.

Desktop environment suck.

Regards,


I agree Nic, and the Torr rating is getting worse all the time.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...)

[Nicolas George]

to...@tuxteam.de (12023-12-21):
> I've sometimes the impression that desktop environments are losing
> the concept pf multi-user operating systems and are regreding to
> something like Windows 95.

Desktop environment and the “modern” applications designed for them had
already lost the ability to put back everything in place by quitting and
restarting. Now they are losing the concept of multiple users, and they
are also losing the ability to run several independent instances of the
same program.

Desktop environment suck.

Regards,

-- 
  Nicolas George

Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...)

[tomas]

On Thu, Dec 21, 2023 at 11:04:35AM -0500, Jeffrey Walton wrote:

[...]

> I think you will find a fair number of Unix & Linux servers set a
> default timezone. I sometimes have to set TZ in my bashrc because of
> an unexpected default timezone. Or that's been my experience at the
> GCC Compile Farm, .

But it's not the "server's timezone". It is the default timezone for
applications which haven't set one themselves (if they care about it
at all).

A "server's timezone" makes so much sense as a "server's $PATH setting".
Or its $LANG.

But I'm out of it.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...)

[Jeffrey Walton]

On Thu, Dec 21, 2023 at 12:51 AM  wrote:
>
> On Thu, Dec 21, 2023 at 10:30:42AM +0700, Max Nikulin wrote:
>
> [...]
>
> > See systemd-timedated.service(8) and org.freedesktop.timedate1(5)
> >
> > busctl introspect org.freedesktop.timedate1 /org/freedesktop/timedate1
> > # Values are stripped
> > org.freedesktop.DBus.Properties interface -
>
> [...]
>
> > Desktop environments use this interface.
>
> Ugh.
>
> [...]
>
> > I would not be surprised to find an "Automatic time zone" checkbox in GUI
> > settings similar to e.g. Android.
>
> Double ugh.
>
> UNIX got that right from the start. Now this crazy notion "the computer
> HAS to have a timezone of its own" is creeping in.
>
> Glad I stay clear from that "Desktop" craze. Thanks for giving me yet
> another reason :-)

I think you will find a fair number of Unix & Linux servers set a
default timezone. I sometimes have to set TZ in my bashrc because of
an unexpected default timezone. Or that's been my experience at the
GCC Compile Farm, .

Jeff

Re: systemd and timezone

[Max Nikulin]

On 21/12/2023 12:33, to...@tuxteam.de wrote:

On Thu, Dec 21, 2023 at 10:30:42AM +0700, Max Nikulin wrote:


busctl introspect org.freedesktop.timedate1 /org/freedesktop/timedate1



Desktop environments use this interface.


Ugh.


I do not see any problem if it is considered as a D-Bus interface to 
/etc/localtime. Users may change timezone from GUI and polkit will show 
a popup requesting password to confirm the action.



I would not be surprised to find an "Automatic time zone" checkbox in GUI
settings similar to e.g. Android.


Double ugh.

UNIX got that right from the start. Now this crazy notion "the computer
HAS to have a timezone of its own" is creeping in.


Even admins may wish to see local time, not UTC in logs. So the D-Bus 
interface is no worse than the /etc/localtime file.


GUI users traveling a lot would be happy to see time suitable for 
current location. A server and a portable device are different use cases 
and different set of features are expected. Those who do not like 
system-wide timezone may set TZ.

Re: systemd and timezone

[Max Nikulin]

On 21/12/2023 21:08, Dan Ritter wrote:

Max Nikulin wrote:

busctl introspect org.freedesktop.timedate1 /org/freedesktop/timedate1


Is this set per-user?


It would be "busctl --user" if it were per-user. This an interface for a 
system-wide setting.



Because I certainly have multiple users on
the same computer at the same time from different timezones. And
it is quite possible on a few of those machines to have multiple
desktop users, each from a different TZ.


Unless TZ is explicitly set or particular applications have their own 
way to configure timezone, users get time in the system time zone.


I have a kind of minimal KDE with enough missed recommended packages. 
Changing time zone in "System Settings" asks for password and updates it 
system-wide. LocalZone in ~/.config/ktimezonedrc just follows 
system-wide settings. Full KDE or e.g. Gnome might allow per-user time 
zone set through GUI. If implemented, I would expect that it will change 
the TZ environment variable.

Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...)

[tomas]

On Thu, Dec 21, 2023 at 09:08:09AM -0500, Dan Ritter wrote:
> Max Nikulin wrote: 
> > I am not going to discuss code posted by Albretch, despite it has serious
> > issues from my point of view. This is a response to Greg.
> > 
> > On 20/12/2023 22:04, Greg Wooledge wrote:
> > > The default time zone has nothing to do with systemd, nor with any other
> > > init system that may be in place.  Systemd does not know or care about
> > > the system's default time zone.
> > 
> > See systemd-timedated.service(8) and org.freedesktop.timedate1(5)
> > 
> > busctl introspect org.freedesktop.timedate1 /org/freedesktop/timedate1
> > # Values are stripped
> > org.freedesktop.DBus.Properties interface -
> > .PropertiesChanged  signalsa{sv}as
> > org.freedesktop.timedate1   interface -
> > .SetTimezonemethodsb
> > .Timezone   property  s
> > 
> > Desktop environments use this interface.
> 
> Is this set per-user? Because I certainly have multiple users on
> the same computer at the same time from different timezones. And
> it is quite possible on a few of those machines to have multiple
> desktop users, each from a different TZ.

I've sometimes the impression that desktop environments are losing
the concept pf multi-user operating systems and are regreding to
something like Windows 95.

But hey. I'm just an old fart ;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...)

[Dan Ritter]

Max Nikulin wrote: 
> I am not going to discuss code posted by Albretch, despite it has serious
> issues from my point of view. This is a response to Greg.
> 
> On 20/12/2023 22:04, Greg Wooledge wrote:
> > The default time zone has nothing to do with systemd, nor with any other
> > init system that may be in place.  Systemd does not know or care about
> > the system's default time zone.
> 
> See systemd-timedated.service(8) and org.freedesktop.timedate1(5)
> 
> busctl introspect org.freedesktop.timedate1 /org/freedesktop/timedate1
> # Values are stripped
> org.freedesktop.DBus.Properties interface -
> .PropertiesChanged  signalsa{sv}as
> org.freedesktop.timedate1   interface -
> .SetTimezonemethodsb
> .Timezone   property  s
> 
> Desktop environments use this interface.

Is this set per-user? Because I certainly have multiple users on
the same computer at the same time from different timezones. And
it is quite possible on a few of those machines to have multiple
desktop users, each from a different TZ.

-dsr-

Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...)

[tomas]

On Thu, Dec 21, 2023 at 10:30:42AM +0700, Max Nikulin wrote:

[...]

> See systemd-timedated.service(8) and org.freedesktop.timedate1(5)
> 
> busctl introspect org.freedesktop.timedate1 /org/freedesktop/timedate1
> # Values are stripped
> org.freedesktop.DBus.Properties interface -

[...]

> Desktop environments use this interface.

Ugh.

[...]

> I would not be surprised to find an "Automatic time zone" checkbox in GUI
> settings similar to e.g. Android.

Double ugh.

UNIX got that right from the start. Now this crazy notion "the computer
HAS to have a timezone of its own" is creeping in.

Glad I stay clear from that "Desktop" craze. Thanks for giving me yet
another reason :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

systemd and timezone (was: Re: difference in seconds between two formatted dates ...)

[Max Nikulin]

I am not going to discuss code posted by Albretch, despite it has 
serious issues from my point of view. This is a response to Greg.


On 20/12/2023 22:04, Greg Wooledge wrote:


The selection of the computer's default time zone by its owner is not
in ANY way related to the computer's geographic location.

The default time zone has nothing to do with systemd, nor with any other
init system that may be in place.  Systemd does not know or care about
the system's default time zone.


See systemd-timedated.service(8) and org.freedesktop.timedate1(5)

busctl introspect org.freedesktop.timedate1 /org/freedesktop/timedate1
# Values are stripped
org.freedesktop.DBus.Properties interface -
.PropertiesChanged  signalsa{sv}as
org.freedesktop.timedate1   interface -
.ListTimezones  method-
.SetLocalRTCmethodbbb
.SetNTP methodbb
.SetTimemethodxbb
.SetTimezonemethodsb
.CanNTP property  b
.LocalRTC   property  b
.NTPproperty  b
.NTPSynchronizedproperty  b
.RTCTimeUSecproperty  t
.TimeUSec   property  t
.Timezone   property  s

Desktop environments use this interface.


Again, you're not making any sense.  How does this computer know where
it is geographically located?  Does it have GPS hardware inside it?
And even knowing a user's geographic location is *not* enough to know
which time zone the user wishes to use. Time zones are poliitical.


I would not be surprised to find an "Automatic time zone" checkbox in 
GUI settings similar to e.g. Android. I am unsure however if it has been 
implemented by any Debian package. Ubuntu installer is able to guess 
time zone. Likely it is based on a GeoIP database and an external server 
to determine outgoing IP address.


List of WiFi networks around is enough to get location without GPS. 
$LANG may improve this guess to resolve political (ethnic) ambiguity.


My impression is that there are enough users who do not know their 
timezone and enough users would be happy to get correct timezone 
automatically. Some of them choose a timezone having slight differences 
and later complain that the TZ DB is not precise.


To configure default timezone system-wide I still recommend

dpkg-reconfigure tzdata

since it handles the case of obsolete application. I would not neglect 
systemd though since it is widespread now. So output of the following 
commands maybe useful to diagnose issues related to localtime


timedatectl
set | grep -E '^(TZ|LANG|LC_.*)='