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