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 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-20 08:40 +0100 |
| Message-ID | <HMZlo-eOjc-7@gated-at.bofh.it> |
| In reply to | #264951 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, Dec 20, 2023 at 12:00:29AM -0600, David Wright wrote: [...] > 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.) Nitpick and reminder: in UNIX and cousins, the "machine" has no timezone. It's the executable (and its children, if they don't change it). See: tomas@trotzki:~$ date Wed Dec 20 08:24:32 CET 2023 tomas@trotzki:~$ TZ=Asia/Singapore bash tomas@trotzki:~$ date Wed Dec 20 15:24:47 +08 2023 tomas@trotzki:~$ exit What is /etc/timezone for, then? you may ask. It's just the default for when you don't pick any. As to gmail... I rather not think about that (still aching from my cognitive dissonance to see someone so much trying to protect himself from intrusion to entrust his communication to the biggest vacuum cleaner for personal data and human behaviour of known history, but I disgress). Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-21 06:00 +0100 |
| Message-ID | <HNjk5-f0Kj-1@gated-at.bofh.it> |
| In reply to | #264954 |
On Wed 20 Dec 2023 at 08:37:46 (+0100), tomas@tuxteam.de wrote: > On Wed, Dec 20, 2023 at 12:00:29AM -0600, David Wright wrote: > > [...] > > > 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.) > > Nitpick and reminder: in UNIX and cousins, the "machine" has no > timezone. It's the executable (and its children, if they don't > change it). See: > > tomas@trotzki:~$ date > Wed Dec 20 08:24:32 CET 2023 > tomas@trotzki:~$ TZ=Asia/Singapore bash > tomas@trotzki:~$ date > Wed Dec 20 15:24:47 +08 2023 > tomas@trotzki:~$ exit > > What is /etc/timezone for, then? you may ask. > > It's just the default for when you don't pick any. Sorry for the synecdoche, but I think it expresses the comprehensive setting of UTC across the entirety of the computer and its operating system, from the RTC, through /etc/timezone and /etc/localhost, to the users' sessions. By this active (not just default) means, users can remain blissfully unaware of the effects of setting timezones other than UTC, just as the OP appeared to be, until reminded. Obviously I have no idea what the OP's actual machine is set up for, and I don't have any clue what their scheme is supposed to achieve. Hence "I wonder whether …" quoted above. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-21 06:40 +0100 |
| Message-ID | <HNjWN-f1ip-9@gated-at.bofh.it> |
| In reply to | #265053 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, Dec 20, 2023 at 10:52:33PM -0600, David Wright wrote: > On Wed 20 Dec 2023 at 08:37:46 (+0100), tomas@tuxteam.de wrote: > > On Wed, Dec 20, 2023 at 12:00:29AM -0600, David Wright wrote: > > > > [...] > > > > > 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.) > > > > Nitpick and reminder: in UNIX and cousins, the "machine" has no > > timezone. It's the executable (and its children, if they don't > > change it). See: > > > > tomas@trotzki:~$ date > > Wed Dec 20 08:24:32 CET 2023 > > tomas@trotzki:~$ TZ=Asia/Singapore bash > > tomas@trotzki:~$ date > > Wed Dec 20 15:24:47 +08 2023 > > tomas@trotzki:~$ exit > > > > What is /etc/timezone for, then? you may ask. > > > > It's just the default for when you don't pick any. > > Sorry for the synecdoche, but I think it expresses the comprehensive > setting of UTC across the entirety of the computer and its operating > system, from the RTC, through /etc/timezone and /etc/localhost, to > the users' sessions. Now I'm confused. The timezone is just a (pointer to a) set of rules stating how to translate UNIX time into a human readable form. So it just touches applications intending to show times to a human. What is the RTC doing here, then? (Now, yes, there is a provision for telling the system that the RTC is broken, because it is shared with another, crippled, operating system, but this is another kettle of fish and has nothing to do with /etc/timezone, and luckily is slowly fading away). Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-22 02:30 +0100 |
| Message-ID | <HNCwp-fcNZ-7@gated-at.bofh.it> |
| In reply to | #265054 |
On Thu 21 Dec 2023 at 06:38:55 (+0100), tomas@tuxteam.de wrote: > On Wed, Dec 20, 2023 at 10:52:33PM -0600, David Wright wrote: > > On Wed 20 Dec 2023 at 08:37:46 (+0100), tomas@tuxteam.de wrote: > > > On Wed, Dec 20, 2023 at 12:00:29AM -0600, David Wright wrote: > > > > > > [...] > > > > > > > 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.) > > > > > > Nitpick and reminder: in UNIX and cousins, the "machine" has no > > > timezone. It's the executable (and its children, if they don't > > > change it). See: > > > > > > tomas@trotzki:~$ date > > > Wed Dec 20 08:24:32 CET 2023 > > > tomas@trotzki:~$ TZ=Asia/Singapore bash > > > tomas@trotzki:~$ date > > > Wed Dec 20 15:24:47 +08 2023 > > > tomas@trotzki:~$ exit > > > > > > What is /etc/timezone for, then? you may ask. > > > > > > It's just the default for when you don't pick any. > > > > Sorry for the synecdoche, but I think it expresses the comprehensive > > setting of UTC across the entirety of the computer and its operating > > system, from the RTC, through /etc/timezone and /etc/localhost, to > > the users' sessions. > > Now I'm confused. The timezone is just a (pointer to a) set of rules > stating how to translate UNIX time into a human readable form. So it > just touches applications intending to show times to a human. > > What is the RTC doing here, then? I was under the impression that the OP had a mode called "unexposed". I assumed that meant that the machine was isolated from other machines. Perhaps I've overlooked some other method of initialising System Time after booting up in unexposed mode, other than the RTC. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-21 13:20 +0100 |
| Message-ID | <HNqbT-f5lB-3@gated-at.bofh.it> |
| In reply to | #265053 |
On Wed, Dec 20, 2023 at 10:52:33PM -0600, David Wright wrote: > Sorry for the synecdoche, but I think it expresses the comprehensive > setting of UTC across the entirety of the computer and its operating > system, from the RTC, through /etc/timezone and /etc/localhost, to > the users' sessions. By this active (not just default) means, users > can remain blissfully unaware of the effects of setting timezones > other than UTC, just as the OP appeared to be, until reminded. I'm not even sure what you're trying to say here. "Active"? Do you think /etc/timezone and /etc/localhost somehow have agency? That they have intent? They're just settings. When an application wants to convert an epoch time to a date/time string, it looks for the TZ environment variable, and if that's not present, it looks for either /etc/localtime or /etc/timezone, depending on how it was programmed. As far as the RTC (real time clock) goes, that just exists to bootstrap the system clock at boot time, before NTP takes over. If the system isn't connected to a network with a time server available, then of course NTP never takes over, and the system clock tries its best to keep up with time based on the initial RTC value, unless/until a sysadmin decides to run a date command to set the system clock more accurately. Again, there isn't any agency here. The RTC is just a resource that the system can use, once per boot, to get things started. It could be set correctly, or incorrectly. It could be set to local time, as was common when dual-booting with Windows, or to UTC. On systems that run NTP, the RTC is mostly vestigial. Its setting has very little effect on anything -- perhaps some early logfile timestamps.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-21 13:30 +0100 |
| Subject | RTC and (old) Windows [was: difference in seconds between two formatted dates ...] |
| Message-ID | <HNqlz-f5oB-1@gated-at.bofh.it> |
| In reply to | #265063 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Dec 21, 2023 at 07:15:12AM -0500, Greg Wooledge wrote: [...] > Again, there isn't any agency here. The RTC is just a resource that > the system can use, once per boot, to get things started. It could > be set correctly, or incorrectly. It could be set to local time, as > was common when dual-booting with Windows, or to UTC. On systems > that run NTP, the RTC is mostly vestigial. Its setting has very > little effect on anything -- perhaps some early logfile timestamps. Anecdote time: I used to work in a shop Back Then (TM) (roughly Windows 3.1). We did C programs for a living and had a mix of Windows boxes and Linux boxes. Windows boxes were "naive" and had local time. We had a time zone with summer and winter time. On time transitions, all hell broke loose with Makefiles, which look at file time stamps :-) We ended up setting the Windows boxes to Monrovia/Liberia: no time jumps *and* (more or less) GMT. No more hassles... Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2023-12-21 23:30 +0100 |
| Subject | Re: RTC and (old) Windows [was: difference in seconds between two formatted dates ...] |
| Message-ID | <HNzId-fb2a-3@gated-at.bofh.it> |
| In reply to | #265065 |
On 12/21/23 04:22, tomas@tuxteam.de wrote: > I used to work in a shop Back Then (TM) (roughly Windows 3.1). We did > C programs for a living and had a mix of Windows boxes and Linux boxes. > > Windows boxes were "naive" and had local time. We had a time zone > with summer and winter time. > > On time transitions, all hell broke loose with Makefiles, which look > at file time stamps :-) > > We ended up setting the Windows boxes to Monrovia/Liberia: no time > jumps *and* (more or less) GMT. No more hassles... That is a great idea -- thank you! :-) David
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-22 02:40 +0100 |
| Message-ID | <HNCG5-fcQY-7@gated-at.bofh.it> |
| In reply to | #265063 |
On Thu 21 Dec 2023 at 07:15:12 (-0500), Greg Wooledge wrote: > On Wed, Dec 20, 2023 at 10:52:33PM -0600, David Wright wrote: > > Sorry for the synecdoche, but I think it expresses the comprehensive > > setting of UTC across the entirety of the computer and its operating > > system, from the RTC, through /etc/timezone and /etc/localhost, to > > the users' sessions. By this active (not just default) means, users > > can remain blissfully unaware of the effects of setting timezones > > other than UTC, just as the OP appeared to be, until reminded. > > I'm not even sure what you're trying to say here. I'm trying to explain something I thought was a simple concept, an "all-UTC machine". So I suggested how you might make one. Take a PC, turn it on, and set the CMOS clock to UTC. Boot it up, run dpkg-reconfigure tzdata and set UTC as the timezone. > "Active"? Do you > think /etc/timezone and /etc/localhost somehow have agency? That > they have intent? No, I just meant that /you/ actively set everything that you could to UTC, as if your universe was set in London on a wintry day. > They're just settings. Yes, and I just meant that you'd have to set the machine's System Timetone to UTC. I'll hazard a guess that most people here won't have that already set as their system timezone. What would "passive" settings be? I don't know, but I've just seen the term used in this thread: https://lists.debian.org/debian-user/2023/12/msg01131.html > As far as the RTC (real time clock) goes, that just exists to > bootstrap the system clock at boot time, before NTP takes over. > If the system isn't connected to a network with a time server > available, then of course NTP never takes over, and the system clock > tries its best to keep up with time based on the initial RTC value, > unless/until a sysadmin decides to run a date command to set the > system clock more accurately. Exactly, so the RTC is the primary source of time for a system in the so-called "unexposed" mode of operation. > Again, there isn't any agency here. The RTC is just a resource that > the system can use, once per boot, to get things started. It could > be set correctly, or incorrectly. It could be set to local time, as > was common when dual-booting with Windows, or to UTC. On systems > that run NTP, the RTC is mostly vestigial. Its setting has very > little effect on anything -- perhaps some early logfile timestamps. Bear in mind that I was explaining my use of "all-UTC machine". Were you to construct such a beast, I think the first thing you might set, actively, is the RTC. You wouldn't just assume that it was already set to UTC. What would be a better term for such a machine in the state described? Anyway, having followed these actions, someone could now write and test scripts without worrying about timezones, and then find out that they fail when someone in the real world runs them. Which is what I posted in: https://lists.debian.org/debian-user/2023/12/msg00915.html on my "exposed" "America/Chicago machine". Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-22 04:10 +0100 |
| Message-ID | <HNE5b-fdNu-3@gated-at.bofh.it> |
| In reply to | #265134 |
On Thu, Dec 21, 2023 at 07:31:31PM -0600, David Wright wrote: > Bear in mind that I was explaining my use of "all-UTC machine". > Were you to construct such a beast, I think the first thing you > might set, actively, is the RTC. You wouldn't just assume that > it was already set to UTC. > > What would be a better term for such a machine in the state described? A non-networked machine with its default time zone set to UTC. The admin would need to keep setting the clock by hand as it drifts, but otherwise, this is not a special or unusual setup... if this were 1990. > Anyway, having followed these actions, someone could now write and > test scripts without worrying about timezones, and then find out that > they fail when someone in the real world runs them. A cynic might observe that nobody else in the world is ever going to run those scripts. But yeah, this is a hive of bugs being hatched. We've pointed out the obvious ones, and that's all we can do for now.
[toc] | [prev] | [next] | [standalone]
| From | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| Date | 2023-12-20 08:50 +0100 |
| Message-ID | <HMZv4-eOmA-11@gated-at.bofh.it> |
| In reply to | #264951 |
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 (remember I am using a Debian Live DVD, on "exposed mode" ;-)) $ date +%z +0000 $ cat /etc/localtime TZif2UTCTZif2UTC UTC0 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. 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? Thank you, lbrtchx
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-20 13:20 +0100 |
| Message-ID | <HN3Il-eR9R-3@gated-at.bofh.it> |
| In reply to | #264957 |
On Wed, Dec 20, 2023 at 07:43:51AM +0000, Albretch Mueller wrote: > 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 ...). You're writing code that's intended to be used by OTHER PEOPLE? Do it CORRECTLY, then!
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-20 13:40 +0100 |
| Message-ID | <HN41H-eRkp-1@gated-at.bofh.it> |
| In reply to | #264960 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, Dec 20, 2023 at 07:15:20AM -0500, Greg Wooledge wrote: > On Wed, Dec 20, 2023 at 07:43:51AM +0000, Albretch Mueller wrote: > > 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 ...). How would this person's computer notice? > You're writing code that's intended to be used by OTHER PEOPLE? > > Do it CORRECTLY, then! Oh, oh. I'd wish more in our profession heeded this. Then, I'd wish my managers gave me the time to actually do it (instead of me having to wrestle that time out of them, time and again). :-) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| Date | 2023-12-20 14:20 +0100 |
| Message-ID | <HN4Ep-eRPP-3@gated-at.bofh.it> |
| In reply to | #264961 |
On 12/20/23, tomas@tuxteam.de <tomas@tuxteam.de> wrote: > On Wed, Dec 20, 2023 at 07:15:20AM -0500, Greg Wooledge wrote: >> On Wed, Dec 20, 2023 at 07:43:51AM +0000, Albretch Mueller wrote: >> > 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 ...). > > How would this person's computer notice? The only way I see is for the running computer on "exposed mode" to check via systemd if the time zone has been changed and reset it in that case before you use date for file naming for all data that is kept in a measured way. In the case of the person flying from Paris to Boston he will find out that he flew away from continental Europe once he reboots his computer in "exposed mode" (pun intended). He will notified of the time zone he had used before and all such deltas will be kept. The only measured data that will be deleted is the one which remains the same. lbrtchx
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-20 14:40 +0100 |
| Message-ID | <HN4XL-eS0d-3@gated-at.bofh.it> |
| In reply to | #264967 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, Dec 20, 2023 at 01:12:35PM +0000, Albretch Mueller wrote: > On 12/20/23, tomas@tuxteam.de <tomas@tuxteam.de> wrote: > > On Wed, Dec 20, 2023 at 07:15:20AM -0500, Greg Wooledge wrote: > >> On Wed, Dec 20, 2023 at 07:43:51AM +0000, Albretch Mueller wrote: > >> > 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 ...). > > > > How would this person's computer notice? > > The only way I see is for the running computer on "exposed mode" to > check via systemd if the time zone has been changed and reset it in > that case before you use date for file naming for all data that is > kept in a measured way. <irony>Lucky me, I'm still on SysV init</irony> You still don't know how this timezone stuff works, do you? Time zone is a *user* concept, not a *system* concept. The system only knows about UNIX time, which is very close to UTC (but not equal). The only thing which might change your time "from the outside" is ntp, to synchronize your clock (including the occasional leap second). > In the case of the person flying from Paris to Boston he will find > out that he flew away from continental Europe once he reboots his > computer in "exposed mode" (pun intended). He will notified of the > time zone he had used before and all such deltas will be kept. The > only measured data that will be deleted is the one which remains the > same. This is not how it works. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-20 16:10 +0100 |
| Message-ID | <HN6mR-eT1y-13@gated-at.bofh.it> |
| In reply to | #264967 |
On Wed, Dec 20, 2023 at 01:12:35PM +0000, Albretch Mueller wrote:
> The only way I see is for the running computer on "exposed mode" to
> check via systemd if the time zone has been changed
Huh? None of this makes any sense. First of all, the system's default
time zone only changes if a user with root privileges decides to change
it. This is done by running "dpkg-reconfigure tzdata", or by manually
editing one file and redirecting one symbolic link, if you're stubborn.
The selection of the computer's default time zone by its owner is not
in ANY way related to the computer's geographic location.
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. "Checking via systemd" is a phrase
with no meaning, in this case.
> and reset it
What? You want your software to *undo* the choices made by the computer's
owner?
> in
> that case before you use date for file naming for all data that is
> kept in a measured way.
So... no, you didn't actually mean "reset the system's default time zone
to a previous value". You mean something like "use the currently
selected default time zone" -- but that's what everything does all
the time, unless the TZ environment variable is set.
I think you need to brush up on the fundamentals here.
> In the case of the person flying from Paris to Boston he will find
> out that he flew away from continental Europe once he reboots his
> computer in "exposed mode" (pun intended).
Again, you're not making any sense. How does this computer know where
it is geographically located? Does it have GPS hardware inside it?
And even knowing a user's geographic location is *not* enough to know
which time zone the user wishes to use. Time zones are poliitical.
There are places on earth where two groups of people in the same
geographic location use two different time zones. Because politics.
> He will notified of the
> time zone he had used before and all such deltas will be kept.
Stop this. Stop this IMMEDIATELY.
Learn how time works. Then rewrite everything.
The system clock stores time as an offset from a fixed point in time
known as "the epoch" -- which is midnight, 1 January 1970, UTC.
This storage form is known as "epoch time" or "Unix time".
When displaying the current time to a user, the epoch time value is
converted into a human-readable time string, using the user's chosen
locale and time zone. Users select these things by setting environment
variables. If the environment variables are not set, the system-wide
default values are used instead.
Right now, as I write this, the epoch time is 1703082118 which is
1.703... billion seconds after the epoch. Using the standard Gregorian
calendar, in the America/New_York time zone, this epoch time value
can be displayed as "Wed Dec 20 09:21:58 EST 2023" which is a string
that makes sense to me, a human being, who lives in this time zone.
It could also be displayed as "Wed Dec 20 09:21:58 AM EST 2023" and
this still makes sense to me. The difference between these two strings
is the locale definition that I, the end user, have chosen for my
environment. It is a personal preference.
Any piece of software that wants to calculate durations needs to work
with epoch times, or something equivalent to epoch times. Two moments
in time must be encoded in a way that they can be subtracted from each
other to determine how much time elapsed between moment one and moment
two.
Since we're on Unix systems which work with epoch time internally, there's
no reason to make up an equivalent, or to reinvent any wheels. Just use
the epoch time values that the system clock is working with already.
So, to be completely blunt here, what you want to do is store ALL
timestamps in epoch time format. This could be a string like
"1703082118", or it could be the raw 64-bit integer which this string
represents. Either way's fine, depending on your programming language
and tool set.
Because you have all your timestamps in epoch format, calculating
intervals is easy -- you just subtract, and that's how many seconds
have elapsed. You can convert this number of seconds to an interval
expressed in other units, like "1 hour, 23 minutes and 17 seconds"
using a bit of arithmetic. Some programming languages may have tools
to do this for you.
If you want to display human-readable time strings corresponding to
your stored epoch times, then you use a tool which takes an epoch
time value as input, and produces a human-readable time string as
output. This is *incredibly complicated* so you do *not* do this
yourself using stone knives and bear skins. You use a *tool* that
has been developed and honed and debugged for decades.
Since your chosen language seems to be bash, you have two good choices
for the tool to do this: bash's builtin printf, or GNU date.
GNU date is easy enough:
unicorn:~$ date -d @1703082118
Wed Dec 20 09:21:58 EST 2023
You can specify a format string, if you don't want the default format.
The end user's environment variables (TZ, LANG, LC_TIME, LC_ALL) will
help determine the output, and so will the system's default time zone
(if TZ is not set).
Bash's printf works quite similarly:
unicorn:~$ printf '%(%c)T\n' 1703082118
Wed Dec 20 09:21:58 2023
Again, the output string is determined by the user's environment and the
system's default time zone (in the absence of a TZ variable). You may
specify a format, and if you do so, it will be used *in conjunction*
with the user's environment to generate the output string.
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.
Think of time strings as "write only". You never read one. You only
write one, and only when the output is intended for human consumption.
If a computer's default time zone is changed, or if a user's TZ variable
is changed, then your programs should translate your stored epoch time
values to different output strings. This is all 100% automatic. If
your software is written properly, you don't need to *do* anything
specifically to handle this. The underlying tools will handle it.
If you have two timestamps (stored in epoch time format) which were
generated when the computer's geographic and political time zones
were different, *you do not care*. The epoch time values are
independent of time zones.
When the timestamp values are displayed to the end user, they will be
displayed in whatever time zone the end user is currently choosing
to operate in, regardless of what time zone the user may have been
operating in when the timestamps were originally stored.
The end user may need to be aware of this. Maybe. It's up to them to
decide whether this is a significant piece of information.
If you, the *developer*, have talked to your end users, and you've
collectively decided that certain timestamp values must be reported
using the time zone that was in use when they were collected, then
you will need to store time zone values alongside the epoch time
values. This will introduce a great deal of additional complexity to
your application, so you should only do this if you've *actually*
determined that it's needed.
In this case, you would need to override the TZ environment variable
each time you display one of these "local timestamps" to the end user.
Once again, the underlying tools will take care of the translation
for you. You "only" need to worry about storing, retrieving, and
temporarily setting these TZ values correctly, and using the right
TZ value with its corresponding epoch time value.
[toc] | [prev] | [next] | [standalone]
| From | Nicolas George <george@nsup.org> |
|---|---|
| Date | 2023-12-20 16:30 +0100 |
| Message-ID | <HN6Ge-eT8j-11@gated-at.bofh.it> |
| In reply to | #264974 |
Greg Wooledge (12023-12-20): > Huh? None of this makes any sense. I salute you for your patience and excellent message. Just a few remarks: > Learn how time works. Then rewrite everything. Fortunately, we do not have to handle relativistic issues à la “meanwhile at the other side of the galaxy”… > Any piece of software that wants to calculate durations needs to work > with epoch times, or something equivalent to epoch times. A small nitpick here NOT RELEVANT TO THE CURRENT DISCUSSION but important if wannabe developers learn things reading you. This is true for long durations, not short durations, with the difference between the two being: is the system allowed to reboot in the middle? If the system might reboot between the beginning and the end, then you are absolutely right, the “wall clock” of Unix systems is the right choice. But if the system cannot reboot unless it makes the duration irrelevant (think: timeout for a network connection), then the right choice is not the wall clock but the monotonic clock. See: https://pubs.opengroup.org/onlinepubs/000095399/functions/clock_gettime.html (For shell, the monotinic time is in /proc/uptime) > So, to be completely blunt here, what you want to do is store ALL > timestamps in epoch time format. This could be a string like > "1703082118", or it could be the raw 64-bit integer which this string > represents. Either way's fine, depending on your programming language > and tool set. A format that can be reliably converted with a rather simple algorithm over the contemporary era, like the ISO time syntax, would be acceptable too. Last: a long time ago, I wrote this for French Usenet (and it somehow found its way on this website; I should publish it on my own): https://www.generation-nt.com/reponses/la-gestion-de-l-heure-sous-linux-entraide-500251.html I think it might be of interest, and nowadays LLMs can translate it correctly I guess. Regards, -- Nicolas George
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-21 04:50 +0100 |
| Subject | systemd and timezone (was: Re: difference in seconds between two formatted dates ...) |
| Message-ID | <HNiel-f09F-1@gated-at.bofh.it> |
| In reply to | #264974 |
I am not going to discuss code posted by Albretch, despite it has
serious issues from my point of view. This is a response to Greg.
On 20/12/2023 22:04, Greg Wooledge wrote:
>
> The selection of the computer's default time zone by its owner is not
> in ANY way related to the computer's geographic location.
>
> 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 -
.ListTimezones method -
.SetLocalRTC method bbb
.SetNTP method bb
.SetTime method xbb
.SetTimezone method sb
.CanNTP property b
.LocalRTC property b
.NTP property b
.NTPSynchronized property b
.RTCTimeUSec property t
.TimeUSec property t
.Timezone property s
Desktop environments use this interface.
> Again, you're not making any sense. How does this computer know where
> it is geographically located? Does it have GPS hardware inside it?
> And even knowing a user's geographic location is *not* enough to know
> which time zone the user wishes to use. Time zones are poliitical.
I would not be surprised to find an "Automatic time zone" checkbox in
GUI settings similar to e.g. Android. I am unsure however if it has been
implemented by any Debian package. Ubuntu installer is able to guess
time zone. Likely it is based on a GeoIP database and an external server
to determine outgoing IP address.
List of WiFi networks around is enough to get location without GPS.
$LANG may improve this guess to resolve political (ethnic) ambiguity.
My impression is that there are enough users who do not know their
timezone and enough users would be happy to get correct timezone
automatically. Some of them choose a timezone having slight differences
and later complain that the TZ DB is not precise.
To configure default timezone system-wide I still recommend
dpkg-reconfigure tzdata
since it handles the case of obsolete application. I would not neglect
systemd though since it is widespread now. So output of the following
commands maybe useful to diagnose issues related to localtime
timedatectl
set | grep -E '^(TZ|LANG|LC_.*)='
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-21 07:00 +0100 |
| Subject | Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) |
| Message-ID | <HNkg9-f1sr-1@gated-at.bofh.it> |
| In reply to | #265049 |
[Multipart message — attachments visible in raw view] — view raw
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 :-) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-21 17:10 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNtMu-f7yV-3@gated-at.bofh.it> |
| In reply to | #265056 |
On 21/12/2023 12:33, tomas@tuxteam.de wrote: > On Thu, Dec 21, 2023 at 10:30:42AM +0700, Max Nikulin wrote: > >> busctl introspect org.freedesktop.timedate1 /org/freedesktop/timedate1 > >> Desktop environments use this interface. > > Ugh. I do not see any problem if it is considered as a D-Bus interface to /etc/localtime. Users may change timezone from GUI and polkit will show a popup requesting password to confirm the action. >> 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. Even admins may wish to see local time, not UTC in logs. So the D-Bus interface is no worse than the /etc/localtime file. GUI users traveling a lot would be happy to see time suitable for current location. A server and a portable device are different use cases and different set of features are expected. Those who do not like system-wide timezone may set TZ.
[toc] | [prev] | [next] | [standalone]
| From | Nicholas Geovanis <nickgeovanis@gmail.com> |
|---|---|
| Date | 2023-12-22 02:00 +0100 |
| Subject | Re: systemd and timezone |
| Message-ID | <HNC3n-fcps-1@gated-at.bofh.it> |
| In reply to | #265096 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Dec 21, 2023, 10:06 AM Max Nikulin <manikulin@gmail.com> wrote: > On 21/12/2023 12:33, tomas@tuxteam.de wrote: > ..... > > > > Double ugh. > > > > UNIX got that right from the start. Now this crazy notion "the computer > > HAS to have a timezone of its own" is creeping in. > > Even admins may wish to see local time, not UTC in logs. So the D-Bus > interface is no worse than the /etc/localtime file. > 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. >
[toc] | [prev] | [next] | [standalone]
Page 2 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