bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: date without time


From: Bruno Haible
Subject: Re: date without time
Date: Fri, 02 Aug 2024 12:50:59 +0200

Alejandro Colomar wrote:
> A day-precission timestamp is a timestamp at any point of that day.
s/precission/precision/ (note that precession is yet another thing).

> (In fact, in /etc/shadow they are stored as full days after Epoch, not
>  as a number of seconds, so it is really a day-precission timestamp.)

And "man 1 shadow" says
    -S, --status
           The third field gives the date of the last password change.

Now I start to understand your problem:

  * /etc/shadow is the same for all users.

  * Either the time stored there is in UTC.
    - Since this field only counts days, not hours, minutes, or seconds,
      no meaningful conversion to local time of the user can be done.
    - But users expect local time output if there is no time zone indication,
      per <https://en.wikipedia.org/wiki/ISO_8601#Local_time_(unqualified)>.
    - So you need to add the time zone abbreviation 'Z':
        $ passwd -S alx
        alx P 2023-09-20Z 0 99999 7 -1

  * Or the time stored there is in the time zone of /etc/localtime.
    - Then, if $TZ and /etc/localtime happen to indicate the same time zone,
      no conversion to local time and no suffix is needed.
    - Otherwise, since users expect local time output if there is no time zone
      indication, you need the RFC 9557 syntax.
    - And there, you get the time zone's name via
        readlink /etc/localtime | sed -e 's|^/usr/share/zoneinfo/||'
        $ passwd -S alx
        alx P 2023-09-20T12:00[America/Los_Angeles] 0 99999 7 -1
      (where 12:00 is just an approximation).

The major problem is thus not a notational problem, but really: Which date
do I present to a user, say, in America/Los_Angeles time zone, for an interval
  2023-09-20T00:00:00Z ... 2023-09-21T00:00:00Z
= 2023-09-19T17:00:00[America/Los_Angeles] ... 
2023-09-20T17:00:00[America/Los_Angeles]
?

The problem could be fixed, of course, by acknowledging in the man page
that the problem does not have a reasonable solution:

  "The third field gives the date of the last password change, or the day
   before or the day after the last password change."

Bruno






reply via email to

[Prev in Thread] Current Thread [Next in Thread]