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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2023-12-22 13:50 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNN8t-fjnQ-13@gated-at.bofh.it> |
| In reply to | #265131 |
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
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Walton <noloader@gmail.com> |
|---|---|
| Date | 2023-12-21 17:30 +0100 |
| Subject | Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) |
| Message-ID | <HNu5Q-f7EN-7@gated-at.bofh.it> |
| In reply to | #265056 |
On Thu, Dec 21, 2023 at 12:51 AM <tomas@tuxteam.de> 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, <https://gcc.gnu.org/wiki/CompileFarm>. Jeff
[toc] | [prev] | [next] | [standalone]
| From | tomas@tuxteam.de |
|---|---|
| Date | 2023-12-21 18:40 +0100 |
| Subject | Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) |
| Message-ID | <HNvbz-f8fU-5@gated-at.bofh.it> |
| In reply to | #265100 |
[Multipart message — attachments visible in raw view] — view raw
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, <https://gcc.gnu.org/wiki/CompileFarm>. 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
[toc] | [prev] | [next] | [standalone]
| From | Dan Ritter <dsr@randomstring.org> |
|---|---|
| Date | 2023-12-21 15:30 +0100 |
| Subject | Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) |
| Message-ID | <HNsdI-f6wJ-17@gated-at.bofh.it> |
| In reply to | #265049 |
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 signal sa{sv}as
> org.freedesktop.timedate1 interface -
> .SetTimezone method sb
> .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-
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-21 16:10 +0100 |
| Subject | Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) |
| Message-ID | <HNsQq-f6ZG-17@gated-at.bofh.it> |
| In reply to | #265081 |
[Multipart message — attachments visible in raw view] — view raw
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 signal sa{sv}as
> > org.freedesktop.timedate1 interface -
> > .SetTimezone method sb
> > .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
[toc] | [prev] | [next] | [standalone]
| From | Nicolas George <george@nsup.org> |
|---|---|
| Date | 2023-12-21 23:00 +0100 |
| Subject | Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) |
| Message-ID | <HNzfb-faCI-17@gated-at.bofh.it> |
| In reply to | #265086 |
tomas@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
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-22 01:00 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNB7j-fbNM-3@gated-at.bofh.it> |
| In reply to | #265120 |
On 12/21/23 16:54, Nicolas George wrote: > tomas@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
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-22 13:50 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNN8t-fjnQ-5@gated-at.bofh.it> |
| In reply to | #265086 |
On 21/12/2023 21:53, tomas@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.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-22 14:40 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNNUR-fjUz-7@gated-at.bofh.it> |
| In reply to | #265147 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Dec 22, 2023 at 07:26:37PM +0700, Max Nikulin wrote: > On 21/12/2023 21:53, tomas@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. > >
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-22 15:20 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNOxz-fkoD-7@gated-at.bofh.it> |
| In reply to | #265150 |
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), 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.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-22 16:50 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNPWF-fl7C-7@gated-at.bofh.it> |
| In reply to | #265152 |
On Fri 22 Dec 2023 at 08:55:04 (-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), 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.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-22 17:30 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNQzn-flAm-3@gated-at.bofh.it> |
| In reply to | #265154 |
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?
[toc] | [prev] | [next] | [standalone]
| From | "Arno Lehmann, ITS" <al@its-lehmann.de> |
|---|---|
| Date | 2023-12-22 20:20 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNTdT-fnfo-11@gated-at.bofh.it> |
| In reply to | #265156 |
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
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-22 21:00 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNTQB-fntj-1@gated-at.bofh.it> |
| In reply to | #265158 |
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....
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-22 20:50 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNTGV-fnp8-3@gated-at.bofh.it> |
| In reply to | #265156 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-22 21:20 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNU9X-fnQ1-11@gated-at.bofh.it> |
| In reply to | #265160 |
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.
[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 | <HO3wC-fwXe-3@gated-at.bofh.it> |
| In reply to | #265164 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Sven Joachim <svenjoac@gmx.de> |
|---|---|
| Date | 2023-12-22 21:20 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNU9X-fnQ1-13@gated-at.bofh.it> |
| In reply to | #265156 |
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
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-22 22:40 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNVpn-fovt-7@gated-at.bofh.it> |
| In reply to | #265163 |
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.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-23 00:30 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNX7P-fpAk-3@gated-at.bofh.it> |
| In reply to | #265167 |
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.
[toc] | [prev] | [next] | [standalone]
Page 3 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