[tz] localized date without time
Alejandro Colomar
alx at kernel.org
Thu Aug 1 11:43:32 UTC 2024
Hi Paul, Serge,
On Thu, Aug 01, 2024 at 10:44:59AM GMT, Alejandro Colomar wrote:
> > > > I don't see any way to print something like 2023-09-21+02:00 in
> > > > standardese. Is this a defect in ISO 8691?
> > >
> > > Sort of, yes. You can use a format like "2023-09-20T00:000-07:00" to follow
> > > the letter of the standard. I would suggest, though, using the format
> > > "2023-09-20 -0700"; this uses an RFC 3339 / ISO 8601 date, space, and
> >
> > FWIW that is definitely my preference, by far - thanks for suggesting it :)
>
> Agree. Thank you all! I'll have a look at adding this to shadow.git.
I've added support for it in my local branch of shadow, but have the
following concern:
$ passwd -S alx
alx P 2023-09-20 0 99999 7 -1
The above corresponds 1:1 in space-separated-fields with /etc/shadow
contents. Some existing scripts might rely on that, and adding the
following could break scripts:
$ sudo ./src/passwd -S alx
alx P 2023-09-20 +0200 0 99999 7 -1
> Have a lovely day!
> Alex
>
> >
> > > time-zone, and this notation would be more useful to human readers even if
> > > it's not specifically called out in the standards.
> > >
> > > If you wanted to get fancy you could append an RFC 9557 suffix but that's
> > > surely overkill for this application.
But Paul's idea of going fancy might be better in our case: RFC 9557
suffixes do not add whitespace, and would allow us to keep a 1:1
relation with /etc/shadow:
$ sudo ./src/passwd -S alx
alx P 2023-09-20[+0200] 0 99999 7 -1
I like this approach the most. Which made me wonder... is date(1)
fancy?
$ date --date='2023-09-20[+0200]'
date: invalid date ‘2023-09-20[+0200]’
$ date --version
date (GNU coreutils) 9.4
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David MacKenzie.
It seems not. Paul, should I report a bug to coreutils, or do you have
plans for it already? It would be interesting if date(1) would accept
these suffixes.
Cheers,
Alex
>
> --
> <https://www.alejandro-colomar.es/>
--
<https://www.alejandro-colomar.es/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/tz/attachments/20240801/bd3b781b/signature.asc>
More information about the tz
mailing list