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 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| Date | 2023-12-17 11:20 +0100 |
| Subject | difference in seconds between two formatted dates ... |
| Message-ID | <HLWpz-eaK0-7@gated-at.bofh.it> |
dt00=$(date +%Y%m%d%H%M%S)
echo "// __ \$dt00: |${dt00}|"
... after some long processing for which seconds would be exact
enough, then I would like to get the seconds elapsed since dt00, like
this:
dt02=$(date +%Y%m%d%H%M%S)
echo "// __ \$dt02: |${dt02}|"
you get seconds in dt00 and dt02 and then the difference. You can't
go: $(( dt02 - dt00 )) because bash Arithmetic is 10-based.
I am pretty sure there is such a thing in bash, but I can't find it in
my scripts.
lbrtchx
[toc] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2023-12-17 12:00 +0100 |
| Message-ID | <HLX2h-eaWv-3@gated-at.bofh.it> |
| In reply to | #264851 |
Hello,
On Sun, Dec 17, 2023 at 10:12:11AM +0000, Albretch Mueller wrote:
> dt00=$(date +%Y%m%d%H%M%S)
> echo "// __ \$dt00: |${dt00}|"
>
> ... after some long processing for which seconds would be exact
> enough, then I would like to get the seconds elapsed since dt00, like
> this:
>
> dt02=$(date +%Y%m%d%H%M%S)
> echo "// __ \$dt02: |${dt02}|"
>
> you get seconds in dt00 and dt02 and then the difference. You can't
> go: $(( dt02 - dt00 )) because bash Arithmetic is 10-based.
Why don't you just get the time as epoch time e.g. "date +%s" and
then you can subtract one from the other¹.
You can also take a copy of the contents of /proc/uptime twice and
subtract one from the other.
Thanks,
Andy
¹ Pedants at this point may feel the need to launch launch into a
sub-thread about how subtracting one epoch time from another doesn't
always produce an accurate duration. I can't stop you, but it won't
be news to me.
--
https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-17 12:10 +0100 |
| Message-ID | <HLXbX-ebfq-1@gated-at.bofh.it> |
| In reply to | #264852 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, Dec 17, 2023 at 10:58:28AM +0000, Andy Smith wrote: [...] > ¹ Pedants at this point may feel the need to launch launch into a > sub-thread about how subtracting one epoch time from another doesn't > always produce an accurate duration. I can't stop you, but it won't > be news to me. They can now rant at two :-) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| Date | 2023-12-17 16:30 +0100 |
| Message-ID | <HM1fz-edF7-1@gated-at.bofh.it> |
| In reply to | #264854 |
On 12/17/23, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> On Sun, Dec 17, 2023 at 10:12:11AM +0000, Albretch Mueller wrote:
>> dt00=$(date +%Y%m%d%H%M%S)
>> echo "// __ \$dt00: |${dt00}|"
>>
>> ... after some long processing for which seconds would be exact
>> enough, then I would like to get the seconds elapsed since dt00, like
>> this:
>>
>> dt02=$(date +%Y%m%d%H%M%S)
>> echo "// __ \$dt02: |${dt02}|"
>
> [...]
>> because bash Arithmetic is 10-based.
>
> You wouldn't expect bash to intuit such a crooky arithmetic as
> Gregorian datetime (and then, based on what? The number beginning
> with 2023? Sounds kind of exciting).
Actually, my basic idea is if you can encode a date using formatting
options this utility provides, then you should be able to decode it
using the same options that same utility provides, no? ... and then
get "seconds since 1970-01-01" which wouldn't matter when you are
computing the difference between two 10-based whole numbers which can
be represented exactly in binary Arithmetic.
> If you could live with a datetime format which date can understand
> (instead of your cobbled-up pseudo numeric monster above) ...
Thank you. I learned something out of it, but I used such "cobbled-up
pseudo numeric monster" because, in kind of a poor-man's "measured"
way, I use size, line count, last mod and sha256 metadata in file
names baselining the system's state. I avoid spaces and any other
characters you can't use in most fs' and/or may be interpreted by
shells or OSs in their own ways.
On 12/17/23, Greg Wooledge <greg@wooledge.org> wrote:
> On Sun, Dec 17, 2023 at 10:12:11AM +0000, Albretch Mueller wrote:
>> ... after some long processing for which seconds would be exact
>> enough, then I would like to get the seconds elapsed since dt00
>
> Are you working in bash, or sh?
bash
> Bash offers some alternatives, to avoid having to fork two date(1)
> processes, light as those are. The first is:
>
> unicorn:~$ printf -v dt00 '%(%s)T' -1
> unicorn:~$ echo "$dt00"
> 1702821082
but this is not what I meant and I am sure you can once again impress
everyone here with your bash skills/wisdom. Is there such a thing as:
dt00=$(date +%Y%m%d%H%M%S)
printf -(whatever the formatting for seconds would be) "${dt00}%Y%m%d%H%M%S"
I dealing with my "exposed mode" kinds of states ;-). I use a
computer which initial state is kept as part of the file name as I
explained, then as part of another ("exposed" or "private") reboot I
want to check that file, so I would not be able to then simply do $((
dt02 - dt00 ))
After rebooting (separately for "exposed" or "private" mode):
a) those kinds of name measured files are checked,
b) if everything is fine you would keep some basic statistics (last
difference; as well as, incrementally, average, stddev, skewness and
kurtosis of differences so far)
c) delete the file(s) previous to the latest one
...
and, no, I am not expecting for bash to do that kind of statistics
for me, but I would love to see once again how wrong I am.
On 12/17/23, Andy Smith <andy@strugglers.net> wrote:
> น Pedants at this point may feel the need to launch launch into a
> sub-thread about how subtracting one epoch time from another doesn't
> always produce an accurate duration. I can't stop you, but it won't
> be news to me.
No calendar issue here. All is needed is turning dates into seconds
to get the time diff in seconds. I am not trying to start a
sub-thread, but how on earth would that not always produce an accurate
duration?
lbrtchx
[toc] | [prev] | [next] | [standalone]
| From | "Andrew M.A. Cater" <amacater@einval.com> |
|---|---|
| Date | 2023-12-17 17:00 +0100 |
| Message-ID | <HM1IB-edOS-1@gated-at.bofh.it> |
| In reply to | #264861 |
On Sun, Dec 17, 2023 at 03:28:58PM +0000, Albretch Mueller wrote:
> On 12/17/23, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> > On Sun, Dec 17, 2023 at 10:12:11AM +0000, Albretch Mueller wrote:
> >> dt00=$(date +%Y%m%d%H%M%S)
> >> echo "// __ \$dt00: |${dt00}|"
> >>
> >> ... after some long processing for which seconds would be exact
> >> enough, then I would like to get the seconds elapsed since dt00, like
> >> this:
> >>
> >> dt02=$(date +%Y%m%d%H%M%S)
> >> echo "// __ \$dt02: |${dt02}|"
> >
> > [...]
> >> because bash Arithmetic is 10-based.
> >
> > You wouldn't expect bash to intuit such a crooky arithmetic as
> > Gregorian datetime (and then, based on what? The number beginning
> > with 2023? Sounds kind of exciting).
>
> Actually, my basic idea is if you can encode a date using formatting
> options this utility provides, then you should be able to decode it
> using the same options that same utility provides, no? ... and then
> get "seconds since 1970-01-01" which wouldn't matter when you are
> computing the difference between two 10-based whole numbers which can
> be represented exactly in binary Arithmetic.
>
> > If you could live with a datetime format which date can understand
> > (instead of your cobbled-up pseudo numeric monster above) ...
>
> Thank you. I learned something out of it, but I used such "cobbled-up
> pseudo numeric monster" because, in kind of a poor-man's "measured"
> way, I use size, line count, last mod and sha256 metadata in file
> names baselining the system's state. I avoid spaces and any other
> characters you can't use in most fs' and/or may be interpreted by
> shells or OSs in their own ways.
>
> > น Pedants at this point may feel the need to launch launch into a
> > sub-thread about how subtracting one epoch time from another doesn't
> > always produce an accurate duration. I can't stop you, but it won't
> > be news to me.
>
> No calendar issue here. All is needed is turning dates into seconds
> to get the time diff in seconds. I am not trying to start a
> sub-thread, but how on earth would that not always produce an accurate
> duration?
>
> lbrtchx
>
https://xkcd.com/2867/ refers,
Andy
(amacater@debian.org)
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-17 17:10 +0100 |
| Message-ID | <HM1Si-ee7Y-17@gated-at.bofh.it> |
| In reply to | #264861 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, Dec 17, 2023 at 03:28:58PM +0000, Albretch Mueller wrote: > On 12/17/23, tomas@tuxteam.de <tomas@tuxteam.de> wrote: [...] > > You wouldn't expect bash to intuit such a crooky arithmetic as > > Gregorian datetime [...] > Actually, my basic idea is if you can encode a date using formatting > options this utility provides, then you should be able to decode it > using the same options that same utility provides, no? Template expansion (printf is kind of that) is usually much easier than parsing. Parsing might even lead to ambiguities unless you have been super careful when "designing" your "language". Just imagine variable-length items (there are none in your case, but how should the parser know that?) This is also why "scanf" is much less useful than "printf". Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2023-12-17 17:40 +0100 |
| Message-ID | <HM2lj-eei1-3@gated-at.bofh.it> |
| In reply to | #264861 |
Hello,
On Sun, Dec 17, 2023 at 03:28:58PM +0000, Albretch Mueller wrote:
> On 12/17/23, Andy Smith <andy@strugglers.net> wrote:
> > subtracting one epoch time from another doesn't always produce
> > an accurate duration.
[…]
> how on earth would that not always produce an accurate duration?
All this paranoia, but in computer time you trust? 😀
Falsehoods programmers believe about time
https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
| From | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| Date | 2023-12-17 23:50 +0100 |
| Message-ID | <HM87n-ehGY-5@gated-at.bofh.it> |
| In reply to | #264865 |
Well, yes, "date --date= ..." doesn't work in the way I would wish
("logically" think about it):
https://www.gnu.org/software/coreutils/manual/html_node/General-date-syntax.html
parsing any format allowed by date:
https://www.gnu.org/software/coreutils/manual/html_node/Date-conversion-specifiers.html
which made me think of how/why did I start using my "coblesome"
formatting, but there is nothing really that homely about it. Those
formatting options are listed right on:
date --help
$ date --version 2>&1 | head -n 1
date (GNU coreutils) 8.32
Based on tomas@tuxteam.de's suggestions I worked around a downright
simple hack around those formatting problematics with coreutils date:
s00=$(date +%s)
dt00=$(date +%Y%m%d%H%M%S)
dttm00ISeks="${dt00:0:4}-${dt00:4:2}-${dt00:6:2}T${dt00:8:2}:${dt00:10:2}:${dt00:12:2}+00:00"
ISeks00=$(date -d"${dttm00ISeks}" +%s)
if [[ $s00 -eq $ISeks00 ]]; then
echo "// __ \$ISeks00: |$ISeks00|, \$dttm00ISeks: |${dttm00ISeks}|
conversion OK!"
else
echo "// __ \$s00: |$s00|, \$dt00: |${dt00}|"
echo "// __ \$ISeks00: |$ISeks00|, \$dttm00ISeks: |${dttm00ISeks}|
conversion NOT OK!"
fi
# 63 weeks 5 days 11 hours 0 minutes et 43 seconds later
s02=$(( s00 + 63*7*24*60*60 + 5*24*60*60 + 11*60*60 + 0*60 + 43))
dt02=$(date --date @${s02} +%Y%m%d%H%M%S)
echo "// __ \$s02: |$s02|, \$dt02: |${dt02}|"
dttm02ISeks="${dt02:0:4}-${dt02:4:2}-${dt02:6:2}T${dt02:8:2}:${dt02:10:2}:${dt02:12:2}+00:00"
ISeks02=$(date -d"${dttm02ISeks}" +%s)
if [[ $s02 -eq $ISeks02 ]]; then
echo "// __ \$ISeks02: |$ISeks02|, \$dttm02ISeks: |${dttm02ISeks}|
conversion OK!"
_diffs=$(( s02 - s00 ))
_diffISeks=$(( ISeks02 - ISeks00 ))
if [[ $_diffs -eq $_diffISeks ]]; then
echo "// __ differences also OK!"
else
echo "// __ differences NOT OK! \$_diffs: |$_diffs|, \$_diffISeks:
|${_diffISeks}|"
fi
else
echo "// __ \$s02: |$s02|, \$dt02: |${dt02}|"
echo "// __ \$ISeks02: |$ISeks02|, \$dttm02ISeks: |${dttm02ISeks}|
conversion NOT OK!"
fi
thank you,
lbrtchx
[toc] | [prev] | [next] | [standalone]
| From | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| Date | 2023-12-18 00:10 +0100 |
| Message-ID | <HM8qJ-ei2D-3@gated-at.bofh.it> |
| In reply to | #264865 |
On 12/17/23, Andy Smith <andy@strugglers.net> wrote: >> how on earth would that not always produce an accurate duration? > > All this paranoia, but in computer time you trust? 😀 > Falsehoods programmers believe about time > https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca and how does my paranoia relate to that wall of itemized statements which could be reduced to just a few? No the earth doesn't revolve around the sun in exactly 356 days, ... and the adoption of the Gregorian calendar already caused quite a fuss in the history of humankind, which, believe me, didn't have to do at all with my paranoia. All my paranoia is talking about is that: 1) for historical reasons going back to the Sumerian/Babylonian civilization, the date format we use is not 10-based 2) coreutils date is not quite true to itself when it comes to en- and decoding its own formatting options 3) since time is a scalar magnitude, a time difference will be constant regardless of my paranoia and the statements on that link you posted. 4) contrary to what happens with floating point numbers (which, in general, you can't represent truthfully as binary), a time difference in seconds is whole number which you can exactly represent as binary. Even people who are not paranoid and know their sh!t would easily see my points. I would say it is primary school Arithmetic. lbrtchx
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-18 01:40 +0100 |
| Message-ID | <HM9PP-eiIQ-5@gated-at.bofh.it> |
| In reply to | #264871 |
On Sun 17 Dec 2023 at 23:00:37 (+0000), Albretch Mueller wrote: > On 12/17/23, Andy Smith <andy@strugglers.net> wrote: > > All this paranoia, but in computer time you trust? 😀 > > Falsehoods programmers believe about time > > https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca > > and how does my paranoia relate to that wall of itemized statements > which could be reduced to just a few? I understood the paranoia related to your earlier post, outlining "exposed" and "private" modes and why you require all this date processing to support them. > 2) coreutils date is not quite true to itself when it comes to en- > and decoding its own formatting options Which of its own formatting options does it not support? $ date -Ins | tee /tmp/d-ins 2023-12-17T18:29:38,909648062-06:00 $ date -d "$(cat /tmp/d-ins)" Sun Dec 17 18:29:38 CST 2023 $ date --rfc-email | tee /tmp/d-ema Sun, 17 Dec 2023 18:29:47 -0600 $ date -d "$(cat /tmp/d-ema)" Sun Dec 17 18:29:47 CST 2023 $ date --rfc-3339=ns | tee /tmp/d-rns 2023-12-17 18:29:54.724220949-06:00 $ date -d "$(cat /tmp/d-rns)" Sun Dec 17 18:29:54 CST 2023 $ date | tee /tmp/d-dat Sun Dec 17 18:30:01 CST 2023 $ date -d "$(cat /tmp/d-dat)" Sun Dec 17 18:30:01 CST 2023 $ All correct. When you write dt00=$(date +%Y%m%d%H%M%S) that's /your/ format, not coreutils'. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| Date | 2023-12-18 02:20 +0100 |
| Message-ID | <HMasx-ejar-1@gated-at.bofh.it> |
| In reply to | #264872 |
On 12/18/23, David Wright <deblis@lionunicorn.co.uk> wrote: > When you write dt00=$(date +%Y%m%d%H%M%S) > that's /your/ format, not coreutils'. I (erroneously?) thought coreutils was maintaining Linux date, so if they tell you on their --help instructions to use certain options (including cobbling them together to your heart's content) and you are telling them you are using their format and how, they should be able to parse that string. ANyway, my hack around it wasn't effortful at all. lbrtchx
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-18 07:00 +0100 |
| Message-ID | <HMePv-elIB-1@gated-at.bofh.it> |
| In reply to | #264874 |
On Mon 18 Dec 2023 at 01:11:26 (+0000), Albretch Mueller wrote: > On 12/18/23, David Wright <deblis@lionunicorn.co.uk> wrote: > > When you write dt00=$(date +%Y%m%d%H%M%S) > > that's /your/ format, not coreutils'. > > I (erroneously?) thought coreutils was maintaining Linux date, so if > they tell you on their --help instructions to use certain options > (including cobbling them together to your heart's content) and you are > telling them you are using their format and how, they should be able > to parse that string. You can prettyprint a timedate with date any way you care to, but scanning a timedate with --date requires care. It's safest if you give it a string in one of its own built-in formats. You appear to be expecting your second date command to somehow guess the format you used in the first command, which obviously can't happen. Another problem in what you posted is that you sometimes run date in your local timezone (generally for the "now" times), but you append +00:00 as the timezone for those --date strings that you construct from several substrings. You need to use UT throughout. > ANyway, my hack around it wasn't effortful at > all. I don't know whether you're referring to something already posted, or some new script written in the wake of what you've read here. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| Date | 2023-12-18 07:10 +0100 |
| Message-ID | <HMeZb-em10-3@gated-at.bofh.it> |
| In reply to | #264879 |
On 12/18/23, David Wright <deblis@lionunicorn.co.uk> wrote: > Another problem in what you posted is that you sometimes run date > in your local timezone (generally for the "now" times), but you > append +00:00 as the timezone for those --date strings that you > construct from several substrings. You need to use UT throughout. What difference would that make when all I need is a time difference? The way I understand such time format issues is that it needs to just be the same in the two dates. >> ANyway, my hack around it wasn't effortful at >> all. > > I don't know whether you're referring to something already posted, > or some new script written in the wake of what you've read here. That silly hack which lousy bash script I posted within its test case lbrtchx
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-18 13:20 +0100 |
| Message-ID | <HMkLg-epHY-5@gated-at.bofh.it> |
| In reply to | #264880 |
On Mon, Dec 18, 2023 at 06:02:48AM +0000, Albretch Mueller wrote: > On 12/18/23, David Wright <deblis@lionunicorn.co.uk> wrote: > > Another problem in what you posted is that you sometimes run date > > in your local timezone (generally for the "now" times), but you > > append +00:00 as the timezone for those --date strings that you > > construct from several substrings. You need to use UT throughout. > > What difference would that make when all I need is a time difference? > The way I understand such time format issues is that it needs to just > be the same in the two dates. The only advantage of storing timestamps in a human-readable format would be that you, the human, can read them and know what they mean. If you wreck this by putting the wrong timezone offset on your human-readable times, then they're no longer human-readable. So there is literally NO point in doing all this stupidly difficult formatting and parsing work, when you could just use seconds-since-epoch format instead. In addition to that, a case has already been shown where your chosen format, with or without a fixed timezone offset, is ambiguous -- it could refer to two different times. This is an issue everywhere daylight saving time is used. It's rare, but it's real.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-18 14:10 +0100 |
| Message-ID | <HMlxE-eqdD-15@gated-at.bofh.it> |
| In reply to | #264881 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, Dec 18, 2023 at 07:16:25AM -0500, Greg Wooledge wrote: [...] > If you wreck this by putting the wrong timezone offset on your > human-readable times [...] If you lie about your time zone you might come in too late for your train :-) > In addition to that, a case has already been shown where your chosen > format, with or without a fixed timezone offset, is ambiguous -- it > could refer to two different times. This is an issue everywhere > daylight saving time is used. It's rare, but it's real. I'm still amazed the OP hasn't understood that "date" can output custom formats -- and that it's not always possible to parse back a date in some custom format into a meaningful timestamp. For an extreme case, just try date +"This is not a date" (with a tip o' the hat to René Magritte). For a less extreme example date +"%H:%M:%S" (I use that every minute in my digital clock display). Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-18 14:20 +0100 |
| Message-ID | <HMlHj-eqgU-3@gated-at.bofh.it> |
| In reply to | #264883 |
On Mon, Dec 18, 2023 at 02:07:14PM +0100, tomas@tuxteam.de wrote: > I'm still amazed the OP hasn't understood that "date" can output > custom formats -- and that it's not always possible to parse back > a date in some custom format into a meaningful timestamp. unicorn:~$ date +"On this the %dth day of the %mth month of the year %Y (Common Era), at %M minutes past the %Hth hour" On this the 18th day of the 12th month of the year 2023 (Common Era), at 15 minutes past the 08th hour unicorn:~$ date -d "$(date +"On this the %dth day of the %mth month of the year %Y (Common Era), at %M minutes past the %Hth hour")" date: invalid date ‘On this the 18th day of the 12th month of the year 2023 (Common Era), at 15 minutes past the 08th hour’ WHAT DO YOU MEAN INVALID DATE, YOU JUST PRODUCED IT!! Yeah, I know, it's ridiculous... but this seems to be the level of discourse required to get through to Albretch.
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2023-12-18 14:40 +0100 |
| Subject | date can't parse its own output was: difference in seconds between two formatted dates ...) |
| Message-ID | <HMm0F-eqn0-5@gated-at.bofh.it> |
| In reply to | #264884 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, Dec 18, 2023 at 08:17:21AM -0500, Greg Wooledge wrote: > On Mon, Dec 18, 2023 at 02:07:14PM +0100, tomas@tuxteam.de wrote: > > I'm still amazed the OP hasn't understood that "date" can output > > custom formats -- and that it's not always possible to parse back > > a date in some custom format into a meaningful timestamp. > > unicorn:~$ date +"On this the %dth day of the %mth month of the year %Y (Common Era), at %M minutes past the %Hth hour" > On this the 18th day of the 12th month of the year 2023 (Common Era), at 15 minutes past the 08th hour > unicorn:~$ date -d "$(date +"On this the %dth day of the %mth month of the year %Y (Common Era), at %M minutes past the %Hth hour")" > date: invalid date ‘On this the 18th day of the 12th month of the year 2023 (Common Era), at 15 minutes past the 08th hour’ How 'bout date -d $(date +"1582-10-08T12:31:19") ...then you'd have to have a stern talk with old Gregor ;-D Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-18 19:40 +0100 |
| Message-ID | <HMqGZ-etbL-5@gated-at.bofh.it> |
| In reply to | #264880 |
[Multipart message — attachments visible in raw view] — view raw
On Mon 18 Dec 2023 at 06:02:48 (+0000), Albretch Mueller wrote: > On 12/18/23, David Wright <deblis@lionunicorn.co.uk> wrote: > > Another problem in what you posted is that you sometimes run date > > in your local timezone (generally for the "now" times), but you > > append +00:00 as the timezone for those --date strings that you > > construct from several substrings. You need to use UT throughout. > > What difference would that make when all I need is a time difference? > The way I understand such time format issues is that it needs to just > be the same in the two dates. > > >> ANyway, my hack around it wasn't effortful at > >> all. > > > > I don't know whether you're referring to something already posted, > > or some new script written in the wake of what you've read here. > > That silly hack which lousy bash script I posted within its test case OK, I tried running it (attached). What should it show? Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-18 20:20 +0100 |
| Message-ID | <HMrjH-etFk-3@gated-at.bofh.it> |
| In reply to | #264890 |
On Mon, Dec 18, 2023 at 12:35:29PM -0600, David Wright wrote:
> OK, I tried running it (attached). What should it show?
That the OP is confused about many things.
> # date --help
No shebang. But the script uses bash syntax. When executed FROM BASH,
the script will "work" because bash will intercept the Exec format error
from the kernel and try again under a child bash shell.
When executing the "script" from any other parent, it will simply fail.
Either the kernel's Exec format error will be treated as a final, fatal
error, or it'll be retried under a child sh shell, which won't be able
to process the bashisms.
> if [[ $s00 -eq $ISeks00 ]]; then
This line is bash syntax, not sh. Here's one of the places it'll fail
if not invoked from bash.
Also, this command is treating the contents of the s00 and ISeks00
variables as strings containing numbers, converting both to integers,
and doing an integer comparison on them. That's fine since they both
came from date +%s, in theory, but it's not a habit one should generally
embrace when comparing command outputs.
Usually one would want a string comparison, which would be done with =
instead of -eq.
> dttm02ISeks="${dt02:0:4}-${dt02:4:2}-${dt02:6:2}T${dt02:8:2}:${dt02:10:2}:${dt02:12:2}+00:00"
More bash syntax. Those string slicing expansions like ${dt02:0:4} are
not valid in 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).
If the conversion is correct (apart from the tz offset), but the epoch
time that results is not correct, then it's very likely the +00:00
that's causing the failure.
I'm in America/New_York, and if I were to try something like this:
read -r s dt < <(date '+%s %Y-%m-%dT%H:%M:%S+00:00')
echo "$s"
date +%s -d"$dt"
I would expect the two numbers printed to be *different* from each other.
A date/time string generated in my time zone but with a forced +00:00
tz offset is simply incorrect, as it would be in most time zones in
the world.
Leaving off the +00:00 would allow it to work *most* of the time, with
the exceptions being the times during a daylight saving transition.
Skipping the date/time string and only using the +%s part would allow
it to work *all* of the time, possibly except for leap seconds (I'm
not up to speed on those).
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-20 07:10 +0100 |
| Message-ID | <HMXWh-eNBt-9@gated-at.bofh.it> |
| In reply to | #264891 |
On Mon 18 Dec 2023 at 14:12:12 (-0500), Greg Wooledge wrote: > On Mon, Dec 18, 2023 at 12:35:29PM -0600, David Wright wrote: > > OK, I tried running it (attached). What should it show? > > That the OP is confused about many things. > > > # date --help > > No shebang. But the script uses bash syntax. When executed FROM BASH, > the script will "work" because bash will intercept the Exec format error > from the kernel and try again under a child bash shell. > > When executing the "script" from any other parent, it will simply fail. > Either the kernel's Exec format error will be treated as a final, fatal > error, or it'll be retried under a child sh shell, which won't be able > to process the bashisms. 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.) I ran it on my machine (America/Chicago) to demonstrate to myself, and also the OP, that the code couldn't be correct. > If the conversion is correct (apart from the tz offset), but the epoch > time that results is not correct, then it's very likely the +00:00 > that's causing the failure. > > I'm in America/New_York, and if I were to try something like this: > > read -r s dt < <(date '+%s %Y-%m-%dT%H:%M:%S+00:00') > echo "$s" > date +%s -d"$dt" > > I would expect the two numbers printed to be *different* from each other. > A date/time string generated in my time zone but with a forced +00:00 > tz offset is simply incorrect, as it would be in most time zones in > the world. > > Leaving off the +00:00 would allow it to work *most* of the time, with > the exceptions being the times during a daylight saving transition. > > Skipping the date/time string and only using the +%s part would allow > it to work *all* of the time, possibly except for leap seconds (I'm > not up to speed on those). AIUI with POSIX timezones, you don't have to worry about leap seconds with computations of this sort: they effectively don't exist. $ TZ=posix/UTC date -d '1972-06-30T23:59:59' '+%s' 78796799 $ TZ=posix/UTC date -d '1972-06-30T23:59:60' '+%s' date: invalid date ‘1972-06-30T23:59:60’ $ TZ=posix/UTC date -d '1972-07-01T00:00:00' '+%s' 78796800 $ TZ=posix/UTC date -d '1972-07-01T00:00:01' '+%s' 78796801 $ as opposed to: $ TZ=right/UTC date -d '1972-06-30T23:59:59' '+%s' 78796799 $ TZ=right/UTC date -d '1972-06-30T23:59:60' '+%s' 78796800 $ TZ=right/UTC date -d '1972-07-01T00:00:00' '+%s' 78796801 $ TZ=right/UTC date -d '1972-07-01T00:00:01' '+%s' 78796802 $ Cheers, David.
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | linux.debian.user
csiph-web