Hi Paul, Link: <https://github.com/shadow-maint/shadow/issues/1057> Currently, shadow utils' passwd(1) (and several other programs) uses UTC time when printing. That is: $ passwd -S alx alx P 2023-09-20 0 99999 7 -1 the date from above is a UTC representation of $ sudo cat /etc/shadow | grep alx | cut -f3 -d: 19620 However, shadow utils programs, such as chage(1), use local time in input. That timestamp was set by chage(1), interpreting a local date: $ sudo chage -d 2023-09-21 alx $ sudo cat /etc/shadow | grep alx | cut -f3 -d: 19620 $ date Wed Jul 31 07:54:17 CEST 2024 This is rather confusing, and we think that passwd(1) should also print the date in local time, when printing human-readable dates. However, I think it might be better to show the timezone information together with the date, to be clear that what we're printing is local time. Do you think that's reasonable? Or maybe it's understood that when printing a date some timezone information is implicitly local? I didn't find any way to print timezone information in ISO 8601, if you don't print the time together with the date. That is, ISO 8601 says: C.1.3.1 Date A date string represents one of the following: • year, month, and day (e.g. 2001-02-03) • year and month (e.g. 2008-12 ) • year (e.g. 2008) and C.1.3.2 Date and Time A date/time string is composed according to one of three representations as illustrated in the following three examples: • 2001-02-03T09:30:01 • 2004-01-01T10:10:10Z • 2004-01-01T10:10:10+05:00 but I don't see any way to print something like 2023-09-21+02:00 in standardese. Is this a defect in ISO 8691? I see that in C.1.3.2, it says "Zone-offset may be omitted or included", so I guess we can just omit it. What do you think we should do? Thanks! And have a lovely day! Alex -- <https://www.alejandro-colomar.es/>
On 2024-07-30 23:04, Alejandro Colomar wrote:
it might be better to show the timezone information together with the date, to be clear that what we're printing is local time.
That would make sense, given that this is a change to behavior and the time zone info will let people know of the change.
maybe it's understood that when printing a date some timezone information is implicitly local?
It's not obvious to everybody.
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 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.
On 2024-07-31 18:49, Paul Eggert via tz wrote:
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"
Ooops, sorry, that first string had an extra "0". It should have been "2023-09-20T00:00-07:00". An inadvertent mistake, which as it happens underscores how unreadable that string is.
On Wed, Jul 31, 2024 at 06:49:44PM -0700, Paul Eggert wrote:
On 2024-07-30 23:04, Alejandro Colomar wrote:
it might be better to show the timezone information together with the date, to be clear that what we're printing is local time.
That would make sense, given that this is a change to behavior and the time zone info will let people know of the change.
maybe it's understood that when printing a date some timezone information is implicitly local?
It's not obvious to everybody.
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 :)
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.
Hi Tim, Paul, Serge, On Wed, Jul 31, 2024 at 09:24:51PM GMT, Serge E. Hallyn wrote:
On Wed, Jul 31, 2024 at 06:49:44PM -0700, Paul Eggert wrote:
On 2024-07-30 23:04, Alejandro Colomar wrote:
it might be better to show the timezone information together with the date, to be clear that what we're printing is local time.
That would make sense, given that this is a change to behavior and the time zone info will let people know of the change.
maybe it's understood that when printing a date some timezone information is implicitly local?
It's not obvious to everybody.
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. 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.
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
On Thu, Aug 01, 2024 at 01:43:36PM GMT, Alejandro Colomar wrote:
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.
Now I remember, coreutils uses gnulib for that, as you told me some time ago. It would be a gnulib report. :) -- <https://www.alejandro-colomar.es/>
Hi Paul, Ping. Could you please have a look at this? We have some nasty bugs in shadow, and are yet undecided on how to fix them. On Thu, Aug 01, 2024 at 01:46:40PM +0200, Alejandro Colomar wrote:
On Thu, Aug 01, 2024 at 01:43:36PM GMT, Alejandro Colomar wrote:
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]’
Does this kind of date-with-timezone look good to you? Would you add support for it in GNU date(1) (via gnulib)? Have a lovely day! Alex
$ 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.
Now I remember, coreutils uses gnulib for that, as you told me some time ago. It would be a gnulib report. :)
Hi Alex, Use "T0" or " 0" zone offset prefix to make it work: $ date -d2023-09-20T0+0200 2023 Sep 19 Tue 16:00:00 $ date -d2023-09-20\ 0+0200 2023 Sep 19 Tue 16:00:00 or maybe add [ T]12:00 to make it less ambiguous when dealing only with dates? I agree that date with zone without time has a useful meaning, so allowing the time to be optional, defaulting to 0 as usual, in strptime(3) and date(1), would be useful. On 2025-02-11 08:57, Alejandro Colomar via tz wrote:
Hi Paul,
Ping. Could you please have a look at this? We have some nasty bugs in shadow, and are yet undecided on how to fix them.
On Thu, Aug 01, 2024 at 01:46:40PM +0200, Alejandro Colomar wrote:
On Thu, Aug 01, 2024 at 01:43:36PM GMT, Alejandro Colomar wrote:
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]’
Does this kind of date-with-timezone look good to you? Would you add support for it in GNU date(1) (via gnulib)?
Have a lovely day! Alex
$ 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.
Now I remember, coreutils uses gnulib for that, as you told me some time ago. It would be a gnulib report. :)
Didn't you all go around on this last August in bug-gnulib? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry
Hi Brian, Paul, On Tue, Feb 11, 2025 at 01:20:33PM -0700, Brian Inglis wrote:
Hi Alex,
Use "T0" or " 0" zone offset prefix to make it work:
Hmmm, T0 is nice. It's not exactly a time without a date, but it can be a workaround. As in, "I just don't care about the time; I'll put a 0".
$ date -d2023-09-20T0+0200 2023 Sep 19 Tue 16:00:00 $ date -d2023-09-20\ 0+0200 2023 Sep 19 Tue 16:00:00
or maybe add [ T]12:00 to make it less ambiguous when dealing only with dates?
12:00 is ambiguous too. As Paul pointed out back in August, there have been days with 48 hours, and I suspect other days have been much shorter than 24 hours. In such cases, the 12:00 trick wouldn't be enough to avoid ambiguity. Also, I think timezones 13 hours away from UTC do exist or have existed in the past, no? I'd prefer a solution that avoids any ambiguity (or one that keeps the ambiguity by not specifying a time at all).
I agree that date with zone without time has a useful meaning, so allowing the time to be optional, defaulting to 0 as usual, in strptime(3) and date(1), would be useful.
Yeah, I guess T0 is a nice workaround.
Now I remember, coreutils uses gnulib for that, as you told me some time ago. It would be a gnulib report. :)
Didn't you all go around on this last August in bug-gnulib?
Ahhh, I had forgotten about that thread. Yes we did. <https://lists.gnu.org/archive/html/bug-gnulib/2024-08/msg00003.html> We didn't really reach a consensus, though. I now see a comment from Paul from back then: | Fourth, RFC 9557 section 1.2 strongly discourages suffixes like | "[+02:00]". That suffix means clocks never change in that location, | which is historically inaccurate everywhere. Instead, you're supposed | to use a suffix like "[Africa/Tripoli]". I view this as a major | objection to Alejandro's proposal for the output of "passwd". I guess I could use [UTC]. Since I only want to print UTC dates, that should work. Does that sound more palatable? | It might make sense to extend parse-datetime (and GNU date -d) to | parse RFC 9557 [time-zone] suffixes, should they become popular. | However, none of this should be needed for the 'passwd' command. For | that, it's probably better just to stick with its current output, | which is just a date without time zone I'm not happy about it. A date without a time zone is understood as a local date. However, what we store are UTC dates, so we'de be misleading the reader. I insist on a method for printing a date with a timezone but without a time. I'm especially interested in the UTC timezone. Have a lovely night! Alex -- <https://www.alejandro-colomar.es/>
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.
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/>
On Wed, 12 Feb 2025 at 03:53, Alejandro Colomar <alx@kernel.org> wrote:
Even if that's non-standard, as long as it's a valid GNU date, I'm happy with it.
I put much more detailed thoughts on both immediate-term fixes and longer-term suggestions on GitHub where they were first requested: https://github.com/shadow-maint/shadow/issues/1202 But, within the scope of this conversation, it mostly boils down to adding one further qualification: "as long as it's a valid GNU date *which matches the actual behavior of the system*" GNU date(1) interprets such "yyyy-mm-ddZ" constructions as 00:00 UTC, but in casual conversation, expiration dates are generally assumed to mean 24:00 by convention unless otherwise specified. Depending on the actual behavior of your system, being more explicit at the expense of some verbosity may be a better longer-term/transitional choice. -- Tim Parenti
On 2025-02-12 10:52, Tim Parenti via tz wrote:
On Wed, 12 Feb 2025 at 03:53, Alejandro Colomar wrote:
Even if that's non-standard, as long as it's a valid GNU date, I'm happy with it. I put much more detailed thoughts on both immediate-term fixes and longer- term suggestions on GitHub where they were first requested: <https://github.com/shadow-maint/shadow/issues/1202> But, within the scope of this conversation, it mostly boils down to adding one further qualification: "as long as it's a valid GNU date /which matches the actual behavior of the system/" GNU date(1) interprets such "yyyy-mm-ddZ" constructions as 00:00 UTC, but in casual conversation, expiration dates are generally assumed to mean 24:00 by convention unless otherwise specified. Depending on the actual behavior of your system, being more explicit at the expense of some verbosity may be a better longer-term/transitional choice. Unfortunately date dislikes 24:00 and requires Z-24:00 or Z+1day (YMMV):
$ date -u -d2023-09-30T24:00:00Z date: invalid date ‘2023-09-30T24:00:00Z’ $ date -u -d2023-09-30Z-24:00 2023 Oct 01 Sun 00:00:00 $ date -u -d2023-09-30Z+1day 2023 Oct 01 Sun 00:00:00 -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry
On Wed, 12 Feb 2025 at 13:17, Brian Inglis via tz <tz@iana.org> wrote:
Unfortunately date dislikes 24:00
While I used 24:00 here as that is more our common parlance, 23:59:59 was my original suggestion, and is broadly acceptable as a common stand-in in both technical and legal contexts. The resulting < vs <= distinction doesn't matter all that much to the broader question of *how* best to communicate an expiration time to an end-user. -- Tim Parenti
On Wed, 31 Jul 2024 at 13:34, Alejandro Colomar via tz <tz@iana.org> 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?
This doesn't particularly strike me as a defect of ISO 8601. The "2023-09-21" only gives a precision of a day, and the "+02:00" (which extends times, not dates) cannot give me enough information to convert it to, say, my locale. In particular, whether I should convert that to "2023-09-20" or "2023-09-21" in my local time (-04:00) is entirely dependent on the time of day, which has gone unspecified, and to convert to "2023-09-20/21" would be incorrect as that has a duration of two days. Those who want to refer to a localized calendar date as an interval could use the corresponding interval (or duration) notations, such as: 2023-09-21T00:00:00+02:00/24:00:00+02:00 2023-09-21T00+02:00/24+02:00 2023-09-21T00+02/P1D -- Tim Parenti
On 2024-07-31 19:00, Tim Parenti wrote:
The "2023-09-21" only gives a precision of a day
What the original email doesn't make clear, is that the original timestamp has an accuracy of only a day. As I understand it, it's counting the number of seconds since 1970-01-01 00:00:00 UTC and dividing by 24*60*60. There's a similar issue in GNU ChangeLog entries, which have lines like "2015-04-03 Ulrich Müller <ulm@gentoo.org>". Some projects want those dates to be in local time, others in UTC. Both approaches have advantages, and the usual tools to generate those lines typically come with options to let you pick the tradition you prefer.
participants (5)
-
Alejandro Colomar -
Brian Inglis -
Paul Eggert -
Serge E. Hallyn -
Tim Parenti