Hi Paul, On Tue, Feb 11, 2025 at 11:06:45PM -0800, Paul Eggert wrote: > On 2025-02-11 07:57, Alejandro Colomar wrote: > > > > $ date --date='2023-09-20[+0200]' > > > > date: invalid date ‘2023-09-20[+0200]’ > > Does this kind of date-with-timezone look good to you? > > Would you add support for it in GNU date(1) (via gnulib)? > > I don't know, it looks a little weird to me. What if the date in question > contains a spring-forward or fall-back transition? No matter which offset > you put in the string, it'll be "wrong" for some reasonable interpretation. > > If I understand things correctly, the underlying system uses UTC dates, so > the actual timestamp range represented is 2023-09-20 02:00:00 +0200 up to > (but not including) 2023-09-21 02:00:00 +0200, regardless of any springs > forward or falls back that day. So perhaps you should just list the starting > timestamp; if you can't allow spaces, use "2023-09-20T02:00:00+0200". That > will work with "date" as-is. > > If "2023-09-20T02:00:00+0200" is too long, just use "2023-09-20Z". This is > easier to read, and it also works with "date" as-is, and the few people who > care about this issue will get used to the notation.
Thanks for the reply!
Actually, it was a mistake from my side to suggest [+02:00] in the
example, since I'm dealing with UTC dates. Let me reformulate:
$ date --date='2023-09-20[UTC]'
Is that something more palatable? That's actually what I want to use.
If you prefer alternative spellings, [+00:00] is also okay to my needs
(spring-forward transitions of fall-back transitions are not a problem,
because I will only express UTC dates). [Z] is also good to me.
Let's try a few things with GNU date(1):
alx@devuan:~$ date --date='2023-09-20[UTC]'
date: invalid date ‘2023-09-20[UTC]’
alx@devuan:~$ date --date='2023-09-20[+00:00]'
date: invalid date ‘2023-09-20[+00:00]’
alx@devuan:~$ date --date='2023-09-20[Z]'
date: invalid date ‘2023-09-20[Z]’
alx@devuan:~$ date --date='2023-09-20Z'
Wed Sep 20 02:00:00 CEST 2023
Actually, shadow could use the fourth syntax, which seems to be already
supported. Even if that's non-standard, as long as it's a valid GNU
date, I'm happy with it. Now I don't remember why I wanted the [], if
plain Z is supported... (maybe I was blindly trying to follow the
standard and forgot to actually test such a simple thing?) Should I
just use that? (I probably should...)
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
