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?