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 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | Charles Curley <charlescurley@charlescurley.com> |
|---|---|
| Date | 2024-01-08 05:10 +0100 |
| Subject | Re: systemd-timesyncd |
| Message-ID | <HTP7z-1ApA-1@gated-at.bofh.it> |
| In reply to | #265636 |
On Mon, 8 Jan 2024 10:02:25 +0700 Max Nikulin <manikulin@gmail.com> wrote: > Isn't it /etc/systemd/timesyncd.conf, not /etc/systemd/timesyncd? It > might be a reason why systemd-timesyncd did not follow configuration. It is indeed /etc/systemd/timesyncd.conf. However, there is also /etc/systemd/timesyncd.conf.d/, so one may drop local configurations into place without mucking in timesyncd.conf. Since systemd-timesyncd provides /etc/systemd/timesyncd.conf, changes to it will likely be overwritten on the next upgrade to systemd-timesyncd. I have: root@jhegaala:~# ls /etc/systemd/timesyncd.conf.d/ 50localTimeServers.conf root@jhegaala:~# cat /etc/systemd/timesyncd.conf.d/50localTimeServers.conf [Time] NTP=192.168.100.12 192.168.100.6 # File of local time servers provided via DHCP and 60ntp. root@jhegaala:~# 60ntp is my own script which picks up time servers from DHCP information and which is run by Network Manager. This machine is a laptop. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
[toc] | [prev] | [next] | [standalone]
| From | Mark Fletcher <mark27q1@gmail.com> |
|---|---|
| Date | 2024-01-08 14:50 +0100 |
| Subject | Re: systemd-timesyncd |
| Message-ID | <HTYaR-1GjS-7@gated-at.bofh.it> |
| In reply to | #265627 |
[Multipart message — attachments visible in raw view] — view raw
Is it supposed to be installed by the net-installer? There does not seem > to be any man pages other than the bog std stuff. When I found the > /etc/systemd/timesyncd I immediately asked the system for man timesyncd, > got this: > gene@coyote:/etc$ man timesyncd > No manual entry for timesyncd > Try man systemd-timesyncd . Usually the systemd explanations are systemd-<whatever>. I’m not at a machine right now to check, but usually that’s the case. Mark
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-23 18:00 +0100 |
| Subject | mktime (was: Re: systemd and timezone) |
| Message-ID | <HOdvX-fCUX-1@gated-at.bofh.it> |
| In reply to | #265162 |
On 23/12/2023 02:41, Jeffrey Walton wrote: > I've found lack of per-thread timezones and libc's inability to > convert time between timezones a bigger problem than other issues, > like explicitly setting a timezone for a process. From my point of view the TZ environment variable makes timezone conversion a rather expensive operation. Some libc limitations are highlighted in https://data.iana.org/time-zones/theory.html#POSIX > The use case is, an appointment needs to be added to a database with > UTC time, but the sender of the appointment uses localtime+timezone > offset, like 1:00 PM PST or 1:00 PM EST. Trying to convert the > localtime+timezone time to UTC (or other timezone) on a server in a > thread is a real nightmare. Also see > <https://sourceware.org/pipermail/libc-help/2021-January/005652.html>. From that message: > * given: '15 Jan 2021 01:24:55 -0800 (PST) Time zone offset is given, so the timestamp can be unambiguously converted to UTC or seconds since epoch. If the DB is Postgres then I would delegate timezone-related computations to it. Posting code that can not be compiled may hide real issue. A couple of issues that may lead to undefined behavior: (info "(libc) Low-Level Time String Parsing") https://www.gnu.org/software/libc/manual/html_node/Low_002dLevel-Time-String-Parsing.html#index-strptime > • Before calling the ‘strptime’ function for a new input string, you > should prepare the TM structure you pass. Normally this will mean > initializing all values to zero. Alternatively, you can set all > fields to values like ‘INT_MAX’, allowing you to determine which > elements were set by the function call. Zero does not work here > since it is a valid value for many of the fields. Before calling mktime set tm_isdst to negative value if you do not know if DST is effective that moment. However being aware of tm_gmtoff GNU extension, I was not expected the following: (info "(libc) Broken-down Time") https://www.gnu.org/software/libc/manual/html_node/Broken_002ddown-Time.html#index-mktime > The ‘mktime’ function ignores the specified contents of the > ‘tm_wday’, ‘tm_yday’, ‘tm_gmtoff’, and ‘tm_zone’ members of the > broken-down time structure. It uses the values of the other > components to determine the calendar time; it’s permissible for > these components to have unnormalized values outside their normal > ranges. The last thing that ‘mktime’ does is adjust the components > of the BROKENTIME structure, including the members that were > initially ignored. So before calling mktime you need to set a timezone having offset of -0800. I have not figured out if the following approach may give incorrect results for some corner cases: - save tm_gmtoff from strptime results - set UTC timezone - call mktime - adjust result by saved tm_gmtoff Besides performance penalty due to tzset() I would not call it "nightmare". Beware with real timezones having DST or other time transitions. GNU libc implementation of mktime may give different results for the same passed argument depending of argument used for previous call. I would consider using some other library instead of libc: - std::chrono (I have heard of other C++ libraries created before chrono was added to the standard) - Qt - timelib C library from PHP P.S. https://stackoverflow.com/questions/11004273/what-is-stdpromise > std::broken_promise is the best named identifier in the standard > library. And there is no std::atomic_future. > – Cubbi Jun 12, 2012 at 22:26 struct tm is referred to as "Broken-down" time
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Walton <noloader@gmail.com> |
|---|---|
| Date | 2023-12-23 19:30 +0100 |
| Subject | Re: mktime (was: Re: systemd and timezone) |
| Message-ID | <HOeV3-fDS6-3@gated-at.bofh.it> |
| In reply to | #265203 |
On Sat, Dec 23, 2023 at 11:56 AM Max Nikulin <manikulin@gmail.com> wrote: > > On 23/12/2023 02:41, Jeffrey Walton wrote: > > I've found lack of per-thread timezones and libc's inability to > > convert time between timezones a bigger problem than other issues, > > like explicitly setting a timezone for a process. > > From my point of view the TZ environment variable makes timezone > conversion a rather expensive operation. Some libc limitations are > highlighted in > https://data.iana.org/time-zones/theory.html#POSIX > > > The use case is, an appointment needs to be added to a database with > > UTC time, but the sender of the appointment uses localtime+timezone > > offset, like 1:00 PM PST or 1:00 PM EST. Trying to convert the > > localtime+timezone time to UTC (or other timezone) on a server in a > > thread is a real nightmare. Also see > > <https://sourceware.org/pipermail/libc-help/2021-January/005652.html>. > > From that message: > > * given: '15 Jan 2021 01:24:55 -0800 (PST) > > Time zone offset is given, so the timestamp can be unambiguously > converted to UTC or seconds since epoch. > > If the DB is Postgres then I would delegate timezone-related > computations to it. > > Posting code that can not be compiled may hide real issue. > > A couple of issues that may lead to undefined behavior: > > (info "(libc) Low-Level Time String Parsing") > https://www.gnu.org/software/libc/manual/html_node/Low_002dLevel-Time-String-Parsing.html#index-strptime > > • Before calling the ‘strptime’ function for a new input string, you > > should prepare the TM structure you pass. Normally this will mean > > initializing all values to zero. Alternatively, you can set all > > fields to values like ‘INT_MAX’, allowing you to determine which > > elements were set by the function call. Zero does not work here > > since it is a valid value for many of the fields. > > Before calling mktime set tm_isdst to negative value if you do not know > if DST is effective that moment. > > However being aware of tm_gmtoff GNU extension, I was not expected the > following: > > (info "(libc) Broken-down Time") > https://www.gnu.org/software/libc/manual/html_node/Broken_002ddown-Time.html#index-mktime > > The ‘mktime’ function ignores the specified contents of the > > ‘tm_wday’, ‘tm_yday’, ‘tm_gmtoff’, and ‘tm_zone’ members of the > > broken-down time structure. It uses the values of the other > > components to determine the calendar time; it’s permissible for > > these components to have unnormalized values outside their normal > > ranges. The last thing that ‘mktime’ does is adjust the components > > of the BROKENTIME structure, including the members that were > > initially ignored. > > So before calling mktime you need to set a timezone having offset of > -0800. I have not figured out if the following approach may give > incorrect results for some corner cases: > > - save tm_gmtoff from strptime results > - set UTC timezone > - call mktime > - adjust result by saved tm_gmtoff > > Besides performance penalty due to tzset() I would not call it "nightmare". > > Beware with real timezones having DST or other time transitions. GNU > libc implementation of mktime may give different results for the same > passed argument depending of argument used for previous call. > > I would consider using some other library instead of libc: > - std::chrono (I have heard of other C++ libraries created before chrono > was added to the standard) > - Qt > - timelib C library from PHP > > P.S. > https://stackoverflow.com/questions/11004273/what-is-stdpromise > > std::broken_promise is the best named identifier in the standard > > library. And there is no std::atomic_future. > > – Cubbi Jun 12, 2012 at 22:26 > struct tm is referred to as "Broken-down" time Here's what someone on the libc mailing list suggested: <https://sourceware.org/pipermail/libc-help/2021-February/005657.html>. I'm not sure why threading broke in Mailman, so the thread could not be followed. I should have posted it with the original email I sent. The person offered some sample code, and stated there's no way to avoid the [thread-unsafe] putenv with TZ. Also note that it does not handle a source timezone string like '15 Jan 2021 01:24:55 -0800 (PST)'. You have to manually set TZ=America/California [?] first. It is not clear to me why the part of the timezone string "-0800 (PST)" is discarded when creating the time structure. The person also suggested using Gnulib. My project was not using Gnulib, so it was not an option. I think what C programmers need is a libtz that works as expected. And it needs to behave exactly like libc so there are no hard to track down bugs. Jeff
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-24 03:40 +0100 |
| Subject | Re: mktime |
| Message-ID | <HOmzf-fIiv-1@gated-at.bofh.it> |
| In reply to | #265210 |
On 24/12/2023 01:09, Jeffrey Walton wrote: > On Sat, Dec 23, 2023 at 11:56 AM Max Nikulin wrote: >> >> (info "(libc) Broken-down Time") >> https://www.gnu.org/software/libc/manual/html_node/Broken_002ddown-Time.html#index-mktime >>> The ‘mktime’ function ignores the specified contents of the >>> ‘tm_wday’, ‘tm_yday’, ‘tm_gmtoff’, and ‘tm_zone’ members of the ---------------------------------^^^^^^^^^ >>> broken-down time structure. It uses the values of the other >>> components to determine the calendar time; it’s permissible for >>> these components to have unnormalized values outside their normal >>> ranges. The last thing that ‘mktime’ does is adjust the components >>> of the BROKENTIME structure, including the members that were >>> initially ignored. >> So before calling mktime you need to set a timezone having offset of >> -0800. I have not figured out if the following approach may give >> incorrect results for some corner cases: >> >> - save tm_gmtoff from strptime results >> - set UTC timezone >> - call mktime >> - adjust result by saved tm_gmtoff >> >> Besides performance penalty due to tzset() I would not call it "nightmare". > Here's what someone on the libc mailing list suggested: > <https://sourceware.org/pipermail/libc-help/2021-February/005657.html>. > I'm not sure why threading broke in Mailman, so the thread could not > be followed. I should have posted it with the original email I sent. I have seen this response and I have decided that it does not address your case of explicitly specified time zone offset. Mhonarc or whatever tool used to publish mailing list archive is known to break threads on month boundary. > The person offered some sample code, and stated there's no way to > avoid the [thread-unsafe] putenv with TZ. I do not mind. It makes timezone conversions quite expensive. > Also note that it does not > handle a source timezone string like '15 Jan 2021 01:24:55 -0800 > (PST)'. You have to manually set TZ=America/California [?] first. It > is not clear to me why the part of the timezone string "-0800 (PST)" > is discarded when creating the time structure. I think, mktime must follow POSIX, otherwise it will be a great pitfall. POSIX has nothing similar to tm_gmtoff. Even when GNU extensions are available, this field still may be 0. Does it mean that mktime should ignore timezone specified in TZ or /etc/localtime and perform conversion in UTC? I am afraid, it is not acceptable. It is explicitly stated in GNU libc docs and I have quoted it in my message. You do not need namely region-based timezone. You may use a fixed-offset zone matching tm_gmtoff. I have outlined another way that uses UTC. In both cases you have to handle tm_gmtoff explicitly in your code. > I think what C programmers need is a libtz that works as expected. And > it needs to behave exactly like libc so there are no hard to track > down bugs. If it would behave exactly like libc then it could not handle time zones in a convenient way. There are several C++ libraries to deal with timezones. Anyway libc is rather limited in respect to various timestamp modifications: get start/end of day, add or subtract day/month, etc. Some projects written in C have their own libraries. I have mentioned timelib from PHP. It seems, nobody is motivated enough to develop a C library that would be suitable for other projects.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-24 08:40 +0100 |
| Subject | Re: mktime (was: Re: systemd and timezone) |
| Message-ID | <HOrfz-fLsg-3@gated-at.bofh.it> |
| In reply to | #265210 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, Dec 23, 2023 at 01:09:02PM -0500, Jeffrey Walton wrote: [...] > On Sat, Dec 23, 2023 at 11:56 AM Max Nikulin <manikulin@gmail.com> wrote: > Here's what someone on the libc mailing list suggested: [...] > The person also suggested using Gnulib. My project was not using > Gnulib, so it was not an option. Thanks for the gnulib pointer. This way I "discovered" the _rz variants (which gnulib provides, and which seem to be at home somewhere in _BSD land). Back when I did more C, I'd loved to have that. I always have seen gnulib as "you need that whenever you're a poor sod on Windows". Learnt something new :) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-28 03:40 +0100 |
| Subject | Re: mktime |
| Message-ID | <HPOtr-gAyH-5@gated-at.bofh.it> |
| In reply to | #265203 |
On 23/12/2023 23:37, Max Nikulin wrote: > However being aware of tm_gmtoff GNU extension, I was not expected the > following: > > (info "(libc) Broken-down Time") > https://www.gnu.org/software/libc/manual/html_node/Broken_002ddown-Time.html#index-mktime >> The ‘mktime’ function ignores the specified contents of the >> ‘tm_wday’, ‘tm_yday’, ‘tm_gmtoff’, and ‘tm_zone’ members of the >> broken-down time structure. It uses the values of the other >> components to determine the calendar time; it’s permissible for >> these components to have unnormalized values outside their normal >> ranges. The last thing that ‘mktime’ does is adjust the components >> of the BROKENTIME structure, including the members that were >> initially ignored. Actually I was confused by https://sourceware.org/pipermail/libc-alpha/2023-January/144860.html mktime version from IANA TZDB repository https://github.com/eggert/tz/ may take into account tm_gmtoff, but does it only to resolve ambiguity of local time close to backward time transition (DST or administrative one). If tm_gmtoff contains a value that is invalid for local time zone then this field is ignored. GNU libc always ignores tm_gmtoff. Getting time_t from "struct tm" with arbitrary tm_gmtoff requires some code around mktime() call.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-21 16:30 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNt9M-f76l-7@gated-at.bofh.it> |
| In reply to | #265081 |
On 21/12/2023 21:08, Dan Ritter wrote: > Max Nikulin wrote: >> busctl introspect org.freedesktop.timedate1 /org/freedesktop/timedate1 > > Is this set per-user? It would be "busctl --user" if it were per-user. This an interface for a system-wide setting. > Because I certainly have multiple users on > the same computer at the same time from different timezones. And > it is quite possible on a few of those machines to have multiple > desktop users, each from a different TZ. Unless TZ is explicitly set or particular applications have their own way to configure timezone, users get time in the system time zone. I have a kind of minimal KDE with enough missed recommended packages. Changing time zone in "System Settings" asks for password and updates it system-wide. LocalZone in ~/.config/ktimezonedrc just follows system-wide settings. Full KDE or e.g. Gnome might allow per-user time zone set through GUI. If implemented, I would expect that it will change the TZ environment variable.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-22 03:20 +0100 |
| Message-ID | <HNDiN-fdiR-1@gated-at.bofh.it> |
| In reply to | #264974 |
On 20/12/2023 22:04, Greg Wooledge wrote:
> The key point here is that you don't STORE these human-readable time
> strings anywhere. You simply *produce* them on demand, using the
> epoch time values that you *do* store.
Greg, I agree to almost everything you write, however I believe that
text timestamp representation is perfectly valid. To be clear, I
consider UTC formatted time as human readable, despite some people are
not comfortable with it:
date --utc --rfc-3339=seconds
2023-12-22 01:38:50+00:00
or
date --utc --iso-8601=seconds
2023-12-22T01:39:07+00:00
from my point of view, it is no worse than seconds since epoch as
integer. In the commands above "--utc" may be omitted since timezone
offset is explicitly specified.
Latest activity related to text timestamp representation (known to me)
is the following draft
https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
"Date and Time on the Internet: Timestamps with additional information"
I would try to avoid storing timestamp in file name. If it is absolutely
necessary and dates are limited to 4-digit years then I would still prefer
date --utc '+%Y%m%d%H%M%S'
20231222014904
to %s seconds (assuming that 60 produced by %S does not cause parser
error). I still consider this format as human readable despite some
inconvenience. I would consider adding "Z" suffix to make it clear that
it is UTC time rather than local one.
Seconds since epoch are suitable in most cases when binary storage is
available. For text storage formatted date may be better. Extra care is
required to properly store formatted local time.
Back to the code posted by Albretch.
I would avoid BASH for any sufficiently complex problem, so I agree with
suggestions posted earlier. On the other hand parser implementation in
date(1) may be more reliable that date-time libraries for some
programming languages.
Invoking date without "--utc" I consider as a call for a trouble due to
absence of time zone offset:
date '+%Y%m%d%H%M%S' # Do not do it
The code may be accidentally run inside an environment with configured
timezone.
I am not sure that UTC is really UTC on that particular machine due to
the following thread, so bizarre results might be expected:
https://lists.debian.org/msgid-search/CAFakBwhvEThCnmbfSA1uZJw1BTTznY+J=gfEGQ1nqRRkzBmyOw@mail.gmail.com
differences between hwclock <-> date due to time zone issues? ...
Thu, 23 Mar 2023 21:41:40 +0000
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-22 08:00 +0100 |
| Message-ID | <HNHFN-ffOV-3@gated-at.bofh.it> |
| In reply to | #265135 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Dec 22, 2023 at 09:15:27AM +0700, Max Nikulin wrote: > On 20/12/2023 22:04, Greg Wooledge wrote: > > The key point here is that you don't STORE these human-readable time > > strings anywhere. You simply *produce* them on demand, using the > > epoch time values that you *do* store. > > Greg, I agree to almost everything you write, however I believe that text > timestamp representation is perfectly valid. To be clear, I consider UTC > formatted time as human readable, despite some people are not comfortable > with it: > > date --utc --rfc-3339=seconds > 2023-12-22 01:38:50+00:00 As long as the time offset is there, you are my guest :-) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-21 05:40 +0100 |
| Message-ID | <HNj0J-f0E4-1@gated-at.bofh.it> |
| In reply to | #264957 |
On Wed 20 Dec 2023 at 07:43:51 (+0000), Albretch Mueller wrote: > On 12/20/23, David Wright <deblis@lionunicorn.co.uk> wrote: > > To be fair to the OP, there was no official "script", but just some code: > > https://lists.debian.org/debian-user/2023/12/msg00894.html > > which I pasted into /tmp/lbrtchx.sh. The filename suffix was a mere > > convenience to make emacs colour the code and tidy the indentation, > > speeding up finding lines broken by the MUA. I then ran it with: > > $ bash /tmp/lbrtchx.sh > > > >> It *looks* like this command is trying to take a date/time string in > >> one format, and convert it to a different format, and then append a > >> +00:00 time zone offset even though that's not the correct offset for > >> the author's time zone (as far as I know). > > > > Yes, I'm guessing that the OP is in my timezone, as just a few of > > their previous posts have -5/-6 offsets. But most are +0, and > > I wonder whether the OP ran this code on an all-UTC machine. > > (IDK whether their using gmail is relevant.) > > If I understand what you seem to not understand about my work around > to get a time difference in seconds out of my "cobblesome" date > formatting for file names, this is my time zone > > $ date +%z > +0000 I guessed that. I didn't "understand" it because you never stated it. > (remember I am using a > Debian Live DVD, on "exposed mode" ;-)) What's that got to do with the price of fish? > $ cat /etc/localtime > TZif2UTCTZif2UTC > UTC0 Take care. That's a binary file. /etc/timezone is the text one. > At the end of the day, all I need is a time difference in seconds > (and yes, milliseconds would be better), which would be the same > regardless of your time zone. A precise clock might be better, then. Computers deliberately play tricks with time to make themselves more useful to the rest of us. > I do see the good in what you are suggesting to me and I will have to > include time zones in the file names as well and deal with the > possible cases (someone working at Charles de Gaulle Airport in > Paris/France boards a plane to Boston Logan/MA/USA ...). But the > actual question I will have to deal with is how to check and possibly > reset the time zone and the time via a network in a reliable way once > a ToG booted computer gains access to the Internet for which I will > have to use systemd-timesyncd when it boots and shuts down/ when it > changes modes. > > Am I clearer now? I was only concerned with the date command's abilities and its interaction with timezones. I'm certainly not going to dive into what lies behind all this stuff, with your talk of "baselining the system's state" and so on. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-21 06:50 +0100 |
| Message-ID | <HNk6t-f1lG-1@gated-at.bofh.it> |
| In reply to | #265052 |
On 21/12/2023 11:37, David Wright wrote:
> On Wed 20 Dec 2023 at 07:43:51 (+0000), Albretch Mueller wrote:
>> $ cat /etc/localtime
>> TZif2UTCTZif2UTC
>> UTC0
> Take care. That's a binary file. /etc/timezone is the text one.
That is why
readlink /etc/localtime
or
ls -l /etc/localtime
as a primary source. For majority using systemd, more detailed report
may be get from
timedatectl
Consider /etc/timezone is a Debian-specific legacy. File a bug against
packages that still use it. Check this file only to confirm that such
legacy applications use consistent configuration
cat /etc/timezone
[toc] | [prev] | [next] | [standalone]
| From | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| Date | 2023-12-21 07:10 +0100 |
| Message-ID | <HNkpP-f1Qd-1@gated-at.bofh.it> |
| In reply to | #265055 |
On 12/21/23, Max Nikulin <manikulin@gmail.com> wrote:
> as a primary source. For majority using systemd
and what would the systemd way to synch the RTC (Real Time Clock) and
UTC? Why is it I am noticing a 14 seconds difference on my computer
(booted with a Debian Live DVD)?
$ readlink /etc/localtime
/usr/share/zoneinfo/Etc/UTC
$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 27 Dec 14 03:14 /etc/localtime ->
/usr/share/zoneinfo/Etc/UTC
$ timedatectl
Local time: Thu 2023-12-21 00:52:20 UTC
Universal time: Thu 2023-12-21 00:52:20 UTC
RTC time: Thu 2023-12-21 00:52:06
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
NTP service: n/a
RTC in local TZ: no
$
lbrtchx
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-21 08:10 +0100 |
| Message-ID | <HNllT-f2u0-1@gated-at.bofh.it> |
| In reply to | #265057 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Dec 21, 2023 at 06:08:26AM +0000, Albretch Mueller wrote: > On 12/21/23, Max Nikulin <manikulin@gmail.com> wrote: > > as a primary source. For majority using systemd > > and what would the systemd way to synch the RTC https://en.wikipedia.org/wiki/Network_Time_Protocol > (Real Time Clock) The "real time clock" is only relevant at boot time, when you don't have access to an NTP server. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-21 13:40 +0100 |
| Message-ID | <HNqvf-f5rz-3@gated-at.bofh.it> |
| In reply to | #265057 |
On Thu, Dec 21, 2023 at 06:08:26AM +0000, Albretch Mueller wrote:
> and what would the systemd way to synch the RTC (Real Time Clock) and
> UTC?
I don't understand this question at all. The system clock value is
normally written to the RTC as a backup when the system shuts down.
Then, the RTC value is read at boot time to initialize the system clock.
> Why is it I am noticing a 14 seconds difference on my computer
> (booted with a Debian Live DVD)?
Because you're not networked? If the system has no time sources to draw
upon, other than its own battery-backed RTC, then it will continue to
drift farther and farther from the correct time.
> $ timedatectl
> Local time: Thu 2023-12-21 00:52:20 UTC
> Universal time: Thu 2023-12-21 00:52:20 UTC
> RTC time: Thu 2023-12-21 00:52:06
> Time zone: Etc/UTC (UTC, +0000)
> System clock synchronized: no
> NTP service: n/a
> RTC in local TZ: no
I don't think this command's output is accurate for systems using NTP
services that *aren't* systemd's. I'm running ntpsec on mine, and I
also get that same "NTP service: n/a" line.
However, I also get "System clock synchronized: yes". I'm honestly
not sure what those two lines mean. I don't know how far I would
trust this command, on systems that are not fully invested in the
systemd takeover.
Hmm... let's try a brief experiment.
unicorn:~$ sudo ln -sf /usr/share/zoneinfo/America/Chicago /etc/localtime
unicorn:~$ timedatectl | grep -m1 zone
Time zone: America/Chicago (CST, -0600)
unicorn:~$ sudo ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime
unicorn:~$ timedatectl | grep -m1 zone
Time zone: America/Chicago (CST, -0600)
unicorn:~$ timedatectl | grep -m1 zone
Time zone: America/New_York (EST, -0500)
There was a fair bit of time elapsed between those last two commands,
as I was busy pasting things into this email. I don't know how long,
exactly. More than a second, but less than two minutes.
So... this is interesting. Apparently timedatectl doesn't simply look
at the target of /etc/localtime. There's a DELAY before the value is
correctly reported. This tells me that timedatectl is in communication
with some process (perhaps PID 1, I don't know), and this other process
only discovers that /etc/localtime has changed after some time has passed.
Is it *polling*? I have no idea, but that's what it looks like.
More and more reasons not to let systemd touch my clock. Not that I
needed more of them, but... here we stand.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-21 16:40 +0100 |
| Message-ID | <HNtjs-f79w-15@gated-at.bofh.it> |
| In reply to | #265066 |
On 21/12/2023 19:38, Greg Wooledge wrote: > On Thu, Dec 21, 2023 at 06:08:26AM +0000, Albretch Mueller wrote: >> Why is it I am noticing a 14 seconds difference on my computer >> (booted with a Debian Live DVD)? Have you executed any commands setting time since boot? Does the difference remain after reboot? >> $ timedatectl >> Local time: Thu 2023-12-21 00:52:20 UTC >> Universal time: Thu 2023-12-21 00:52:20 UTC >> RTC time: Thu 2023-12-21 00:52:06 >> Time zone: Etc/UTC (UTC, +0000) >> System clock synchronized: no >> NTP service: n/a >> RTC in local TZ: no > > I don't think this command's output is accurate for systems using NTP > services that *aren't* systemd's. I'm running ntpsec on mine, and I > also get that same "NTP service: n/a" line. You may try to pull more NTP-related info from timedatectl. I am unsure if ntpsec is supported. > However, I also get "System clock synchronized: yes". I'm honestly > not sure what those two lines mean. "NTPSynchronized shows whether the kernel reports the time as synchronized (c.f. adjtimex(3))." > Hmm... let's try a brief experiment. [...] > unicorn:~$ timedatectl | grep -m1 zone > Time zone: America/Chicago (CST, -0600) > unicorn:~$ timedatectl | grep -m1 zone > Time zone: America/New_York (EST, -0500) [...] > So... this is interesting. Apparently timedatectl doesn't simply look > at the target of /etc/localtime. There's a DELAY before the value is > correctly reported. This tells me that timedatectl is in communication > with some process (perhaps PID 1, I don't know), and this other process > only discovers that /etc/localtime has changed after some time has passed. I have another guess. systemd-timedated is activated on demand and reads /etc/localtime. It exits a half of a minute later. Perhaps second command caused start of new process since the old one was dead already. I do not think that it expect that something changes /etc/localtime behind the scene. I admit inotify might be implemented, but expected way is to call "timedatectl set-timezone ZONE".
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-21 19:30 +0100 |
| Message-ID | <HNvXX-f8KI-1@gated-at.bofh.it> |
| In reply to | #265093 |
On Thu, Dec 21, 2023 at 10:36:06PM +0700, Max Nikulin wrote: > I have another guess. systemd-timedated is activated on demand and reads > /etc/localtime. It exits a half of a minute later. Perhaps second command > caused start of new process since the old one was dead already. Hmm. OK, logs do seem to support that this could be the case. unicorn:~$ sudo systemctl status systemd-timedated [...] Dec 21 07:18:14 unicorn systemd[1]: Starting systemd-timedated.service - Time &> Dec 21 07:18:14 unicorn systemd[1]: Started systemd-timedated.service - Time & > Dec 21 07:18:44 unicorn systemd[1]: systemd-timedated.service: Deactivated succ> Dec 21 07:25:47 unicorn systemd[1]: Starting systemd-timedated.service - Time &> Dec 21 07:25:47 unicorn systemd[1]: Started systemd-timedated.service - Time & > Dec 21 07:26:39 unicorn systemd[1]: systemd-timedated.service: Deactivated succ> Dec 21 07:26:59 unicorn systemd[1]: Starting systemd-timedated.service - Time &> Dec 21 07:26:59 unicorn systemd[1]: Started systemd-timedated.service - Time & > Dec 21 07:27:29 unicorn systemd[1]: systemd-timedated.service: Deactivated succ> > I do not think that it expect that something changes /etc/localtime behind > the scene. I admit inotify might be implemented, but expected way is to call > "timedatectl set-timezone ZONE". "Expected" by... well, not by *me*, that's for sure. Maybe expected by systemd developers? Now I'm really curious what that command does. Let's find out. unicorn:~$ sudo timedatectl set-timezone America/Chicago unicorn:~$ ls -ld /etc/timezone /etc/localtime lrwxrwxrwx 1 root root 37 Dec 21 12:18 /etc/localtime -> ../usr/share/zoneinfo/America/Chicago -rw-r--r-- 1 root root 17 Dec 9 07:33 /etc/timezone Looks like it does NOT know about Debian's legacy /etc/timezone file, and does not update it. I therefore cannot recommend that anyone on a Debian system use this command to change their time zone, unless they follow it up by manually editing /etc/timezone.
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-21 21:00 +0100 |
| Message-ID | <HNxn4-f9tA-3@gated-at.bofh.it> |
| In reply to | #265066 |
On 12/21/23 07:38, Greg Wooledge wrote: > On Thu, Dec 21, 2023 at 06:08:26AM +0000, Albretch Mueller wrote: >> and what would the systemd way to synch the RTC (Real Time Clock) and >> UTC? > > I don't understand this question at all. The system clock value is > normally written to the RTC as a backup when the system shuts down. > Then, the RTC value is read at boot time to initialize the system clock. > >> Why is it I am noticing a 14 seconds difference on my computer >> (booted with a Debian Live DVD)? > > Because you're not networked? If the system has no time sources to draw > upon, other than its own battery-backed RTC, then it will continue to > drift farther and farther from the correct time. > >> $ timedatectl >> Local time: Thu 2023-12-21 00:52:20 UTC >> Universal time: Thu 2023-12-21 00:52:20 UTC >> RTC time: Thu 2023-12-21 00:52:06 >> Time zone: Etc/UTC (UTC, +0000) >> System clock synchronized: no >> NTP service: n/a >> RTC in local TZ: no > > I don't think this command's output is accurate for systems using NTP > services that *aren't* systemd's. I'm running ntpsec on mine, and I > also get that same "NTP service: n/a" line. > > However, I also get "System clock synchronized: yes". I'm honestly > not sure what those two lines mean. I don't know how far I would > trust this command, on systems that are not fully invested in the > systemd takeover. > > Hmm... let's try a brief experiment. > > unicorn:~$ sudo ln -sf /usr/share/zoneinfo/America/Chicago /etc/localtime > unicorn:~$ timedatectl | grep -m1 zone > Time zone: America/Chicago (CST, -0600) > unicorn:~$ sudo ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime > unicorn:~$ timedatectl | grep -m1 zone > Time zone: America/Chicago (CST, -0600) > unicorn:~$ timedatectl | grep -m1 zone > Time zone: America/New_York (EST, -0500) > > There was a fair bit of time elapsed between those last two commands, > as I was busy pasting things into this email. I don't know how long, > exactly. More than a second, but less than two minutes. > > So... this is interesting. Apparently timedatectl doesn't simply look > at the target of /etc/localtime. There's a DELAY before the value is > correctly reported. This tells me that timedatectl is in communication > with some process (perhaps PID 1, I don't know), and this other process > only discovers that /etc/localtime has changed after some time has passed. > Is it *polling*? I have no idea, but that's what it looks like. > > More and more reasons not to let systemd touch my clock. Not that I > needed more of them, but... here we stand. > > . can us see your /etc/ntpsec/ntp.conf? And, do you have a /var/log/ntpsec subdir ownwd by ntpsec:ntpsec? 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 | 2023-12-21 21:10 +0100 |
| Message-ID | <HNxwJ-f9Ma-3@gated-at.bofh.it> |
| In reply to | #265109 |
On Thu, Dec 21, 2023 at 02:51:50PM -0500, gene heskett wrote: > can us see your /etc/ntpsec/ntp.conf? And, do you have a > /var/log/ntpsec subdir ownwd by ntpsec:ntpsec? unicorn:~$ ls -ld /var/log/ntpsec /etc/ntpsec/ntp.conf ls: cannot access '/var/log/ntpsec': No such file or directory -rw-r--r-- 1 root root 1922 Jan 16 2023 /etc/ntpsec/ntp.conf My ntp.conf file was migrated from a Debian 11 /etc/ntp.conf file, with whatever adjustments the ntp -> ntpsec transition scripts did to it. Should be very generic, but here you go. ============================================================================== # /etc/ntpsec/ntp.conf, configuration for ntpd; see ntp.conf(5) for help driftfile /var/lib/ntpsec/ntp.drift leapfile /usr/share/zoneinfo/leap-seconds.list # To enable Network Time Security support as a server, obtain a certificate # (e.g. with Let's Encrypt), configure the paths below, and uncomment: # nts cert CERT_FILE # nts key KEY_FILE # nts enable # You must create /var/log/ntpsec (owned by ntpsec:ntpsec) to enable logging. #statsdir /var/log/ntpsec/ #statistics loopstats peerstats clockstats #filegen loopstats file loopstats type day enable #filegen peerstats file peerstats type day enable #filegen clockstats file clockstats type day enable # This should be maxclock 7, but the pool entries count towards maxclock. tos maxclock 11 # Comment this out if you have a refclock and want it to be able to discipline # the clock by itself (e.g. if the system is not connected to the network). tos minclock 4 minsane 3 # Specify one or more NTP servers. # Public NTP servers supporting Network Time Security: # server time.cloudflare.com nts # pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will # pick a different set every time it starts up. Please consider joining the # pool: <https://www.pool.ntp.org/join.html> pool 0.debian.pool.ntp.org iburst pool 1.debian.pool.ntp.org iburst pool 2.debian.pool.ntp.org iburst pool 3.debian.pool.ntp.org iburst # Access control configuration; see /usr/share/doc/ntpsec-doc/html/accopt.html # for details. # # Note that "restrict" applies to both servers and clients, so a configuration # that might be intended to block requests from certain clients could also end # up blocking replies from your own upstream servers. # By default, exchange time with everybody, but don't allow configuration. restrict default kod nomodify nopeer noquery limited # Local users may interrogate the ntp server more closely. restrict 127.0.0.1 restrict ::1 ============================================================================== Now let's look for logs. unicorn:/var/log$ sudo grep ntpsec * [...] syslog.1:2023-12-16T15:01:52.641110-05:00 unicorn ntpd[815]: statistics directory /var/log/ntpsec/ does not exist or is unwriteable, error No such file or directory Well, look at that. I wonder why the ntpsec package didn't create that. Let's take a look at <https://bugs.debian.org/ntpsec> and see if there's already a report for it. Here we go: <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049424> "ntpsec: Missing /var/log/ntpsec is logged as an error" So I guess one's expected to create this themselves, but only if they care enough to do it...? Weird.
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-21 21:40 +0100 |
| Message-ID | <HNxZL-f9Ve-3@gated-at.bofh.it> |
| In reply to | #265112 |
On 12/21/23 15:04, Greg Wooledge wrote: > On Thu, Dec 21, 2023 at 02:51:50PM -0500, gene heskett wrote: >> can us see your /etc/ntpsec/ntp.conf? And, do you have a >> /var/log/ntpsec subdir ownwd by ntpsec:ntpsec? > > unicorn:~$ ls -ld /var/log/ntpsec /etc/ntpsec/ntp.conf > ls: cannot access '/var/log/ntpsec': No such file or directory > -rw-r--r-- 1 root root 1922 Jan 16 2023 /etc/ntpsec/ntp.conf > > My ntp.conf file was migrated from a Debian 11 /etc/ntp.conf > file, with whatever adjustments the ntp -> ntpsec transition scripts > did to it. Should be very generic, but here you go. > > ============================================================================== > # /etc/ntpsec/ntp.conf, configuration for ntpd; see ntp.conf(5) for help > > driftfile /var/lib/ntpsec/ntp.drift > leapfile /usr/share/zoneinfo/leap-seconds.list > > # To enable Network Time Security support as a server, obtain a certificate > # (e.g. with Let's Encrypt), configure the paths below, and uncomment: > # nts cert CERT_FILE > # nts key KEY_FILE > # nts enable > > # You must create /var/log/ntpsec (owned by ntpsec:ntpsec) to enable logging. > #statsdir /var/log/ntpsec/ > #statistics loopstats peerstats clockstats > #filegen loopstats file loopstats type day enable > #filegen peerstats file peerstats type day enable > #filegen clockstats file clockstats type day enable > > # This should be maxclock 7, but the pool entries count towards maxclock. > tos maxclock 11 > > # Comment this out if you have a refclock and want it to be able to discipline > # the clock by itself (e.g. if the system is not connected to the network). > tos minclock 4 minsane 3 > > # Specify one or more NTP servers. > > # Public NTP servers supporting Network Time Security: > # server time.cloudflare.com nts > > # pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will > # pick a different set every time it starts up. Please consider joining the > # pool: <https://www.pool.ntp.org/join.html> > pool 0.debian.pool.ntp.org iburst > pool 1.debian.pool.ntp.org iburst > pool 2.debian.pool.ntp.org iburst > pool 3.debian.pool.ntp.org iburst > > # Access control configuration; see /usr/share/doc/ntpsec-doc/html/accopt.html > # for details. > # > # Note that "restrict" applies to both servers and clients, so a configuration > # that might be intended to block requests from certain clients could also end > # up blocking replies from your own upstream servers. > > # By default, exchange time with everybody, but don't allow configuration. > restrict default kod nomodify nopeer noquery limited > > # Local users may interrogate the ntp server more closely. > restrict 127.0.0.1 > restrict ::1 > ============================================================================== > > Now let's look for logs. > > unicorn:/var/log$ sudo grep ntpsec * > [...] > syslog.1:2023-12-16T15:01:52.641110-05:00 unicorn ntpd[815]: statistics directory /var/log/ntpsec/ does not exist or is unwriteable, error No such file or directory > > Well, look at that. I wonder why the ntpsec package didn't create that. > Let's take a look at <https://bugs.debian.org/ntpsec> and see if there's > already a report for it. > > Here we go: <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049424> > "ntpsec: Missing /var/log/ntpsec is logged as an error" > > So I guess one's expected to create this themselves, but only if they > care enough to do it...? Weird. > > . unforch it does not create them and in my recent experience it may run but does not work without being able to log. I created it that subdir and chowned it, then I went around to my other machines doing likewise and the other machines now use this one as a stratum 2 server. by removing the pool 0,1,2,3 entries from their ntp.conf is removing 6 other machines from the traffic into debian's ntp server pool. Those of us with goodly sized private networks hiding behind a NATing router should do that to reduce the load on debians ntp server pool. Even with a stratum 2 rating, you are still within a microsecond of the cesium beam clock in Boulder Colorado USA. When I first set it up a week ago, I quickly found I was part of a pool and had external to my local network clients, but I finally found how to stop that. 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 7 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