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.
