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

Reply via email to