On Sun 17 Dec 2023 at 15:28:58 (+0000), Albretch Mueller wrote: > On 12/17/23, to...@tuxteam.de <to...@tuxteam.de> wrote: > > On Sun, Dec 17, 2023 at 10:12:11AM +0000, Albretch Mueller wrote: > >> dt00=$(date +%Y%m%d%H%M%S)
> Actually, my basic idea is if you can encode a date using formatting > options this utility provides, then you should be able to decode it > using the same options that same utility provides, no? ... and then > get "seconds since 1970-01-01" which wouldn't matter when you are > computing the difference between two 10-based whole numbers which can > be represented exactly in binary Arithmetic. date -d expects "mostly free format human readable", which means it won't work with arbitrary fixed formats, unless they conform to certain standards … > > If you could live with a datetime format which date can understand > > (instead of your cobbled-up pseudo numeric monster above) ... > > Thank you. I learned something out of it, but I used such "cobbled-up > pseudo numeric monster" because, in kind of a poor-man's "measured" > way, I use size, line count, last mod and sha256 metadata in file > names baselining the system's state. I avoid spaces and any other > characters you can't use in most fs' and/or may be interpreted by > shells or OSs in their own ways. Perhaps add five characters (- - T : :) to your poor-man's format, and stick to UTC. If the colons are an embarrassment, sed them to hyphens for filenames and back again for date -d. If that's too much lengthening, just use sed alone to insert/remove those five characters appropriately. Something like: $ LC_ALL=C TZ=UT date -d "$(sed -E 's/(....)(..)(..)(..)(..)(..)/\1-\2-\3T\4:\5:\6/' <<<'19631122183000')" +'%s' -192778200 $ LC_ALL=C TZ=UT date -d '@-192778200' +'%Y%m%d%H%M%S' 19631122183000 $ Cheers, David.