On 20/12/2023 22:04, Greg Wooledge wrote:
The key point here is that you don't STORE these human-readable time
strings anywhere. You simply *produce* them on demand, using the
epoch time values that you *do* store.
Greg, I agree to almost everything you write, however I believe that
text timestamp representation is perfectly valid. To be clear, I
consider UTC formatted time as human readable, despite some people are
not comfortable with it:
date --utc --rfc-3339=seconds
2023-12-22 01:38:50+00:00
or
date --utc --iso-8601=seconds
2023-12-22T01:39:07+00:00
from my point of view, it is no worse than seconds since epoch as
integer. In the commands above "--utc" may be omitted since timezone
offset is explicitly specified.
Latest activity related to text timestamp representation (known to me)
is the following draft
https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
"Date and Time on the Internet: Timestamps with additional information"
I would try to avoid storing timestamp in file name. If it is absolutely
necessary and dates are limited to 4-digit years then I would still prefer
date --utc '+%Y%m%d%H%M%S'
20231222014904
to %s seconds (assuming that 60 produced by %S does not cause parser
error). I still consider this format as human readable despite some
inconvenience. I would consider adding "Z" suffix to make it clear that
it is UTC time rather than local one.
Seconds since epoch are suitable in most cases when binary storage is
available. For text storage formatted date may be better. Extra care is
required to properly store formatted local time.
Back to the code posted by Albretch.
I would avoid BASH for any sufficiently complex problem, so I agree with
suggestions posted earlier. On the other hand parser implementation in
date(1) may be more reliable that date-time libraries for some
programming languages.
Invoking date without "--utc" I consider as a call for a trouble due to
absence of time zone offset:
date '+%Y%m%d%H%M%S' # Do not do it
The code may be accidentally run inside an environment with configured
timezone.
I am not sure that UTC is really UTC on that particular machine due to
the following thread, so bizarre results might be expected:
https://lists.debian.org/msgid-search/CAFakBwhvEThCnmbfSA1uZJw1BTTznY+J=gfegq1nqrrkzbm...@mail.gmail.com
differences between hwclock <-> date due to time zone issues? ...
Thu, 23 Mar 2023 21:41:40 +0000
