Re: difference in seconds between two formatted dates ...
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.
Reply to: