[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