On Wed 20 Dec 2023 at 07:43:51 (+0000), Albretch Mueller wrote: > 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 > > $ date +%z > +0000
I guessed that. I didn't "understand" it because you never stated it. > (remember I am using a > Debian Live DVD, on "exposed mode" ;-)) What's that got to do with the price of fish? > $ cat /etc/localtime > TZif2UTCTZif2UTC > UTC0 Take care. That's a binary file. /etc/timezone is the text one. > 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. A precise clock might be better, then. Computers deliberately play tricks with time to make themselves more useful to the rest of us. > 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? I was only concerned with the date command's abilities and its interaction with timezones. I'm certainly not going to dive into what lies behind all this stuff, with your talk of "baselining the system's state" and so on. Cheers, David.
