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.
