Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #264851 > unrolled thread
| Started by | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| First post | 2023-12-17 11:20 +0100 |
| Last post | 2023-12-17 15:10 +0100 |
| Articles | 20 on this page of 166 — 34 participants |
Back to article view | Back to linux.debian.user
difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-17 11:20 +0100
Re: difference in seconds between two formatted dates ... Andy Smith <andy@strugglers.net> - 2023-12-17 12:00 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-17 12:10 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-17 16:30 +0100
Re: difference in seconds between two formatted dates ... "Andrew M.A. Cater" <amacater@einval.com> - 2023-12-17 17:00 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-17 17:10 +0100
Re: difference in seconds between two formatted dates ... Andy Smith <andy@strugglers.net> - 2023-12-17 17:40 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-17 23:50 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-18 00:10 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-18 01:40 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-18 02:20 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-18 07:00 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-18 07:10 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-18 13:20 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-18 14:10 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-18 14:20 +0100
date can't parse its own output was: difference in seconds between two formatted dates ...) <tomas@tuxteam.de> - 2023-12-18 14:40 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-18 19:40 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-18 20:20 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-20 07:10 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-20 08:40 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-21 06:00 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-21 06:40 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-22 02:30 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-21 13:20 +0100
RTC and (old) Windows [was: difference in seconds between two formatted dates ...] <tomas@tuxteam.de> - 2023-12-21 13:30 +0100
Re: RTC and (old) Windows [was: difference in seconds between two formatted dates ...] David Christensen <dpchrist@holgerdanske.com> - 2023-12-21 23:30 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-22 02:40 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-22 04:10 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-20 08:50 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-20 13:20 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-20 13:40 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-20 14:20 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-20 14:40 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-20 16:10 +0100
Re: difference in seconds between two formatted dates ... Nicolas George <george@nsup.org> - 2023-12-20 16:30 +0100
systemd and timezone (was: Re: difference in seconds between two formatted dates ...) Max Nikulin <manikulin@gmail.com> - 2023-12-21 04:50 +0100
Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) <tomas@tuxteam.de> - 2023-12-21 07:00 +0100
Re: systemd and timezone Max Nikulin <manikulin@gmail.com> - 2023-12-21 17:10 +0100
Re: systemd and timezone Nicholas Geovanis <nickgeovanis@gmail.com> - 2023-12-22 02:00 +0100
Re: systemd and timezone Andy Smith <andy@strugglers.net> - 2023-12-22 13:50 +0100
Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) Jeffrey Walton <noloader@gmail.com> - 2023-12-21 17:30 +0100
Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) tomas@tuxteam.de - 2023-12-21 18:40 +0100
Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) Dan Ritter <dsr@randomstring.org> - 2023-12-21 15:30 +0100
Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) <tomas@tuxteam.de> - 2023-12-21 16:10 +0100
Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) Nicolas George <george@nsup.org> - 2023-12-21 23:00 +0100
Re: systemd and timezone gene heskett <gheskett@shentel.net> - 2023-12-22 01:00 +0100
Re: systemd and timezone Max Nikulin <manikulin@gmail.com> - 2023-12-22 13:50 +0100
Re: systemd and timezone <tomas@tuxteam.de> - 2023-12-22 14:40 +0100
Re: systemd and timezone Greg Wooledge <greg@wooledge.org> - 2023-12-22 15:20 +0100
Re: systemd and timezone David Wright <deblis@lionunicorn.co.uk> - 2023-12-22 16:50 +0100
Re: systemd and timezone Greg Wooledge <greg@wooledge.org> - 2023-12-22 17:30 +0100
Re: systemd and timezone "Arno Lehmann, ITS" <al@its-lehmann.de> - 2023-12-22 20:20 +0100
Re: systemd and timezone Greg Wooledge <greg@wooledge.org> - 2023-12-22 21:00 +0100
Re: systemd and timezone David Wright <deblis@lionunicorn.co.uk> - 2023-12-22 20:50 +0100
Re: systemd and timezone Greg Wooledge <greg@wooledge.org> - 2023-12-22 21:20 +0100
Re: systemd and timezone David Wright <deblis@lionunicorn.co.uk> - 2023-12-23 07:20 +0100
Re: systemd and timezone Sven Joachim <svenjoac@gmx.de> - 2023-12-22 21:20 +0100
Re: systemd and timezone Greg Wooledge <greg@wooledge.org> - 2023-12-22 22:40 +0100
Re: systemd and timezone David Wright <deblis@lionunicorn.co.uk> - 2023-12-23 00:30 +0100
Re: systemd and timezone Pocket <pocket@columbus.rr.com> - 2023-12-23 00:50 +0100
Re: systemd and timezone Pocket <pocket@columbus.rr.com> - 2023-12-23 01:10 +0100
Re: systemd and timezone David Wright <deblis@lionunicorn.co.uk> - 2023-12-23 07:20 +0100
Re: Support for SysV service scripts deprecated in systemd 255 (was: systemd and timezone) Felix Miata <mrmazda@earthlink.net> - 2023-12-23 08:10 +0100
Re: systemd and timezone Pocket <pocket@columbus.rr.com> - 2023-12-23 12:10 +0100
Re: systemd and timezone Nate Bargmann <n0nb@n0nb.us> - 2023-12-23 02:00 +0100
Re: systemd and timezone Greg Wooledge <greg@wooledge.org> - 2023-12-23 02:20 +0100
Re: systemd and timezone <tomas@tuxteam.de> - 2023-12-22 17:10 +0100
Re: systemd and timezone Jeffrey Walton <noloader@gmail.com> - 2023-12-22 21:00 +0100
Re: systemd and timezone Nicolas George <george@nsup.org> - 2023-12-22 23:40 +0100
Re: systemd and timezone Charles Kroeger <mbone@gmx.co.uk> - 2024-01-06 03:30 +0100
Re: systemd and timezone Greg Wooledge <greg@wooledge.org> - 2024-01-06 05:30 +0100
Re: systemd and timezone gene heskett <gheskett@shentel.net> - 2024-01-06 06:40 +0100
tzdata-legacy [was: Re: systemd and timezone] Max Nikulin <manikulin@gmail.com> - 2024-01-06 07:20 +0100
Re: tzdata-legacy [was: Re: systemd and timezone] Max Nikulin <manikulin@gmail.com> - 2024-01-06 08:10 +0100
Re: tzdata-legacy [was: Re: systemd and timezone] Nate Bargmann <n0nb@n0nb.us> - 2024-01-06 10:20 +0100
Re: tzdata-legacy [was: Re: systemd and timezone] gene heskett <gheskett@shentel.net> - 2024-01-06 13:10 +0100
Re: tzdata-legacy [was: Re: systemd and timezone] Greg Wooledge <greg@wooledge.org> - 2024-01-06 16:10 +0100
Re: tzdata-legacy [was: Re: systemd and timezone] David Wright <deblis@lionunicorn.co.uk> - 2024-01-07 18:30 +0100
was: Re: tzdata-legacy [was: Re: systemd and timezone] gene heskett <gheskett@shentel.net> - 2024-01-06 13:00 +0100
Re: was: Re: tzdata-legacy [was: Re: systemd and timezone] John Hasler <john@sugarbit.com> - 2024-01-06 15:30 +0100
SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemd and timezone] gene heskett <gheskett@shentel.net> - 2024-01-06 20:10 +0100
Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemd and timezone] John Hasler <john@sugarbit.com> - 2024-01-06 20:40 +0100
Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemdand timezone] gene heskett <gheskett@shentel.net> - 2024-01-06 21:40 +0100
Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemdand timezone] Nate Bargmann <n0nb@n0nb.us> - 2024-01-06 23:10 +0100
Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemdand timezone] Greg Wooledge <greg@wooledge.org> - 2024-01-07 01:10 +0100
Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemdandtimezone] gene heskett <gheskett@shentel.net> - 2024-01-07 05:30 +0100
Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemdandtimezone] Nate Bargmann <n0nb@n0nb.us> - 2024-01-07 12:30 +0100
Re: SOLVED FOR GENE Felix Miata <mrmazda@earthlink.net> - 2024-01-07 12:40 +0100
Re: SOLVED FOR GENE jeremy ardley <jeremy.ardley@gmail.com> - 2024-01-07 13:10 +0100
Re: SOLVED FOR GENE john doe <johndoe65534@mail.com> - 2024-01-07 13:40 +0100
Re: SOLVED FOR GENE Michael Stone <mstone@debian.org> - 2024-01-11 14:30 +0100
Re: SOLVED FOR GENE Felix Miata <mrmazda@earthlink.net> - 2024-01-11 18:10 +0100
manpages package [WAS Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemd and timezone] "Andrew M.A. Cater" <amacater@einval.com> - 2024-01-06 23:50 +0100
Re: was: Re: tzdata-legacy [was: Re: systemd and timezone] Max Nikulin <manikulin@gmail.com> - 2024-01-06 18:10 +0100
Re: was: Re: tzdata-legacy [was: Re: systemd and timezone] gene heskett <gheskett@shentel.net> - 2024-01-06 20:40 +0100
systemd-timesyncd Max Nikulin <manikulin@gmail.com> - 2024-01-07 16:50 +0100
Re: systemd-timesyncd John Hasler <john@sugarbit.com> - 2024-01-07 17:30 +0100
Re: systemd-timesyncd gene heskett <gheskett@shentel.net> - 2024-01-07 21:20 +0100
Re: systemd-timesyncd Charles Kroeger <mbone@gmx.co.uk> - 2024-01-08 06:50 +0100
Re: systemd-timesyncd gene heskett <gheskett@shentel.net> - 2024-01-07 21:10 +0100
Re: systemd-timesyncd "Andrew M.A. Cater" <amacater@einval.com> - 2024-01-07 22:00 +0100
Re: systemd-timesyncd Charles Curley <charlescurley@charlescurley.com> - 2024-01-08 00:00 +0100
Re: systemd-timesyncd Nicholas Geovanis <nickgeovanis@gmail.com> - 2024-01-08 01:40 +0100
VAX emulation/simulation (was Re: systemd-timesyncd) The Wanderer <wanderer@fastmail.fm> - 2024-01-08 02:10 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) Bret Busby <bret@busby.net> - 2024-01-08 10:40 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) "Jeremy Nicoll" <jn.ml.dbi.73@letterboxes.org> - 2024-01-08 11:40 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-08 13:20 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) Nicholas Geovanis <nickgeovanis@gmail.com> - 2024-01-09 01:00 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-09 09:20 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) Bret Busby <bret@busby.net> - 2024-01-09 10:40 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-09 11:20 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) Nicolas George <george@nsup.org> - 2024-01-09 11:40 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) gene heskett <gheskett@shentel.net> - 2024-01-09 12:30 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) "Niall O'Reilly" <niall+lists@no8.be> - 2024-01-08 21:50 +0100
Re: systemd-timesyncd gene heskett <gheskett@shentel.net> - 2024-01-08 16:00 +0100
Re: systemd-timesyncd gene heskett <gheskett@shentel.net> - 2024-01-08 16:00 +0100
Re: systemd-timesyncd Max Nikulin <manikulin@gmail.com> - 2024-01-08 04:40 +0100
Re: systemd-timesyncd Curt <curty@free.fr> - 2024-01-08 18:00 +0100
Re: systemd-timesyncd Max Nikulin <manikulin@gmail.com> - 2024-01-08 04:20 +0100
Re: systemd-timesyncd Charles Curley <charlescurley@charlescurley.com> - 2024-01-08 05:10 +0100
Re: systemd-timesyncd Mark Fletcher <mark27q1@gmail.com> - 2024-01-08 14:50 +0100
mktime (was: Re: systemd and timezone) Max Nikulin <manikulin@gmail.com> - 2023-12-23 18:00 +0100
Re: mktime (was: Re: systemd and timezone) Jeffrey Walton <noloader@gmail.com> - 2023-12-23 19:30 +0100
Re: mktime Max Nikulin <manikulin@gmail.com> - 2023-12-24 03:40 +0100
Re: mktime (was: Re: systemd and timezone) <tomas@tuxteam.de> - 2023-12-24 08:40 +0100
Re: mktime Max Nikulin <manikulin@gmail.com> - 2023-12-28 03:40 +0100
Re: systemd and timezone Max Nikulin <manikulin@gmail.com> - 2023-12-21 16:30 +0100
Re: difference in seconds between two formatted dates ... Max Nikulin <manikulin@gmail.com> - 2023-12-22 03:20 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-22 08:00 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-21 05:40 +0100
Re: difference in seconds between two formatted dates ... Max Nikulin <manikulin@gmail.com> - 2023-12-21 06:50 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-21 07:10 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-21 08:10 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-21 13:40 +0100
Re: difference in seconds between two formatted dates ... Max Nikulin <manikulin@gmail.com> - 2023-12-21 16:40 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-21 19:30 +0100
Re: difference in seconds between two formatted dates ... gene heskett <gheskett@shentel.net> - 2023-12-21 21:00 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-21 21:10 +0100
Re: difference in seconds between two formatted dates ... gene heskett <gheskett@shentel.net> - 2023-12-21 21:40 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-21 22:40 +0100
Re: difference in seconds between two formatted dates ... gene heskett <gheskett@shentel.net> - 2023-12-22 00:40 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-25 16:40 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-25 18:40 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-26 08:00 +0100
Re: difference in seconds between two formatted dates ... "Thomas Schmitt" <scdbackup@gmx.net> - 2023-12-26 08:30 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-26 16:00 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-26 16:40 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-26 19:40 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-26 22:40 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-27 01:40 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-27 01:50 +0100
When strace breaks process or is blocked (was: Re: difference in seconds between two formatted dates ...) Max Nikulin <manikulin@gmail.com> - 2023-12-27 17:50 +0100
Re: difference in seconds between two formatted dates ... Max Nikulin <manikulin@gmail.com> - 2023-12-18 03:30 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-25 00:10 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-25 01:10 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-25 01:30 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-25 02:20 +0100
Re: difference in seconds between two formatted dates ... "Andrew M.A. Cater" <amacater@einval.com> - 2023-12-25 11:40 +0100
Re: difference in seconds between two formatted dates ... Tixy <tixy@yxit.co.uk> - 2023-12-25 09:10 +0100
Re: difference in seconds between two formatted dates ... Andy Smith <andy@strugglers.net> - 2023-12-27 00:00 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-17 19:00 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-17 19:30 +0100
Re: difference in seconds between two formatted dates ... Teemu Likonen <tlikonen@iki.fi> - 2023-12-17 12:50 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-17 12:10 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-17 15:10 +0100
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | Pocket <pocket@columbus.rr.com> |
|---|---|
| Date | 2023-12-23 00:50 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNXrb-fpGY-3@gated-at.bofh.it> |
| In reply to | #265172 |
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 <https://wiki.debian.org/TimeZoneChanges>. 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
[toc] | [prev] | [next] | [standalone]
| From | Pocket <pocket@columbus.rr.com> |
|---|---|
| Date | 2023-12-23 01:10 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNXKx-fq2Y-5@gated-at.bofh.it> |
| In reply to | #265172 |
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 <https://wiki.debian.org/TimeZoneChanges>. 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
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-23 07:20 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HO3wB-fwXe-1@gated-at.bofh.it> |
| In reply to | #265177 |
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 <https://wiki.debian.org/TimeZoneChanges>. 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.
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2023-12-23 08:10 +0100 |
| Subject | Re: Support for SysV service scripts deprecated in systemd 255 (was: systemd and timezone) |
| Message-ID | <HO4iZ-fxxF-1@gated-at.bofh.it> |
| In reply to | #265180 |
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
[toc] | [prev] | [next] | [standalone]
| From | Pocket <pocket@columbus.rr.com> |
|---|---|
| Date | 2023-12-23 12:10 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HO83g-fzTG-3@gated-at.bofh.it> |
| In reply to | #265180 |
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 <https://wiki.debian.org/TimeZoneChanges>. 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
[toc] | [prev] | [next] | [standalone]
| From | Nate Bargmann <n0nb@n0nb.us> |
|---|---|
| Date | 2023-12-23 02:00 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNYwV-fqZG-1@gated-at.bofh.it> |
| In reply to | #265167 |
[Multipart message — attachments visible in raw view] — view raw
* 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 <https://wiki.debian.org/TimeZoneChanges>. 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
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-23 02:20 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNYQh-fryJ-1@gated-at.bofh.it> |
| In reply to | #265178 |
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.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-22 17:10 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNQg1-fltX-1@gated-at.bofh.it> |
| In reply to | #265152 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Dec 22, 2023 at 08:55:04AM -0500, Greg Wooledge wrote: > On Fri, Dec 22, 2023 at 02:17:47PM +0100, tomas@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
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Walton <noloader@gmail.com> |
|---|---|
| Date | 2023-12-22 21:00 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNTQB-fntj-9@gated-at.bofh.it> |
| In reply to | #265150 |
On Fri, Dec 22, 2023 at 8:33 AM <tomas@tuxteam.de> 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 <https://sourceware.org/pipermail/libc-help/2021-January/005652.html>. Jeff
[toc] | [prev] | [next] | [standalone]
| From | Nicolas George <george@nsup.org> |
|---|---|
| Date | 2023-12-22 23:40 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNWlr-fp51-9@gated-at.bofh.it> |
| In reply to | #265162 |
[Multipart message — attachments visible in raw view] — view raw
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
[toc] | [prev] | [next] | [standalone]
| From | Charles Kroeger <mbone@gmx.co.uk> |
|---|---|
| Date | 2024-01-06 03:30 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HT4BH-16Np-1@gated-at.bofh.it> |
| In reply to | #265170 |
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 <bdrung@debian.org> 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)
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-01-06 05:30 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HT6tP-17YH-5@gated-at.bofh.it> |
| In reply to | #265564 |
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.
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-01-06 06:40 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HT7zz-195l-3@gated-at.bofh.it> |
| In reply to | #265567 |
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
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-01-06 07:20 +0100 |
| Subject | tzdata-legacy [was: Re: systemd and timezone] |
| Message-ID | <HT8ci-19yk-3@gated-at.bofh.it> |
| In reply to | #265569 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-01-06 08:10 +0100 |
| Subject | Re: tzdata-legacy [was: Re: systemd and timezone] |
| Message-ID | <HT8YF-1a5d-9@gated-at.bofh.it> |
| In reply to | #265570 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Nate Bargmann <n0nb@n0nb.us> |
|---|---|
| Date | 2024-01-06 10:20 +0100 |
| Subject | Re: tzdata-legacy [was: Re: systemd and timezone] |
| Message-ID | <HTb0t-1boP-3@gated-at.bofh.it> |
| In reply to | #265571 |
[Multipart message — attachments visible in raw view] — view raw
* 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
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-01-06 13:10 +0100 |
| Subject | Re: tzdata-legacy [was: Re: systemd and timezone] |
| Message-ID | <HTdEZ-1d5A-27@gated-at.bofh.it> |
| In reply to | #265574 |
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
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-01-06 16:10 +0100 |
| Subject | Re: tzdata-legacy [was: Re: systemd and timezone] |
| Message-ID | <HTgtb-1eMZ-13@gated-at.bofh.it> |
| In reply to | #265574 |
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. <https://data.iana.org/time-zones/theory.html> 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.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-01-07 18:30 +0100 |
| Subject | Re: tzdata-legacy [was: Re: systemd and timezone] |
| Message-ID | <HTF8d-1ukv-1@gated-at.bofh.it> |
| In reply to | #265574 |
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.
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-01-06 13:00 +0100 |
| Subject | was: Re: tzdata-legacy [was: Re: systemd and timezone] |
| Message-ID | <HTdvj-1cMM-3@gated-at.bofh.it> |
| In reply to | #265570 |
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
[toc] | [prev] | [next] | [standalone]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | linux.debian.user
csiph-web