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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* 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

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

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

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

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

Re: systemd and timezone

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

Re: systemd and timezone

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

Re: systemd and timezone

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

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

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.

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

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

mktime (was: Re: systemd and timezone)

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

Re: systemd and timezone

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.

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

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/

Re: systemd and timezone

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.

Re: systemd and timezone

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: > > > >

Re: systemd and timezone

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

* 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

Re: systemd and timezone

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

Re: systemd and timezone

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

Re: systemd and timezone

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

Re: systemd and timezone

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

Re: systemd and timezone

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

Re: systemd and timezone

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

Re: systemd and timezone

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 >

Re: systemd and timezone

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

Re: systemd and timezone

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

Re: systemd and timezone

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.

Re: systemd and timezone

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

Re: systemd and timezone

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

Re: systemd and timezone

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

Re: systemd and timezone

fied 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 &

Re: systemd and timezone

ess 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. timedatec

Re: systemd and timezone

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

Re: systemd and timezone

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

Re: systemd and timezone

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

Re: systemd and timezone

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

Re: systemd and timezone

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

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

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

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

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

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

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

Re: systemd and timezone

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

Re: systemd and timezone

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

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

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

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

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

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

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 - [...] >

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

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