On 12/20/23, David Wright <deb...@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
