Re: date without time

[Alejandro Colomar]

Hi Bruno,

On Fri, Aug 02, 2024 at 12:50:59PM GMT, Bruno Haible wrote:
> 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).

Thanks!  There are several words which I always incorrectly remember as
having double-s.  :)

> > (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.

It's even worse than that.  :)

The time stored in /etc/shadow is in UTC, but:

-  It was (or could be) originated in local time.  That is:

        $ sudo chage -d 2023-09-21 alx
        $ 

   The above interprets 2023-09-21 as 2023-09-21T00:00:00+0200, and
   transforms it into a UTC day-precision timestamp by calculating the
   UTC day that contained that moment.

        $ date -u --date 2023-09-21T00:00:00+0200
        Wed Sep 20 22:00:00 UTC 2023

-  And so the stored value is a UTC value (of course; otherwise a change
   in local time would change the meaning of the timestamps).
   It stores as if 2023-09-20Z had been passed to chage(1):

        $ sudo cat /etc/shadow | grep alx | cut -f3 -d:
        19620

   Which corresponds to:

        $ expr 19620 \* 86400 | xargs printf '@%s' | xargs date --date
        Wed Sep 20 02:00:00 CEST 2023
        $ expr 19620 \* 86400 | xargs printf '@%s' | xargs date -u --date
        Wed Sep 20 00:00:00 UTC 2023

-  When we print that, we need to decide:

   Should we just admit that it's Zulu time?
   Should we translate back to local time?
   In any case we need to specify so.  Either with Z, or a RFC 9557
   suffix.

   Until yesterday, we printed the UTC timestamp, without specifying Z.

>     - Since this field only counts days, not hours, minutes, or seconds,
>       no meaningful conversion to local time of the user can be done.

We can still have a day-precision timestamp, calculated in the inverse
way that chage(1) did.  That is, calculate the local day that contained
the moment described by the UTC timestamp.

In fact, yesterday we started doing so.  We still don't specify the
time zone information, so the timestamp is a bit ambiguous (as it was
already, so not much is lost or won; we get more consistency, though).

The behavior in passwd(1) in shadow.git HEAD is to transform the
timestamp into local time, by finding the local-time day that contains
the moment represented by the UTC timestamp.

>     - But users expect local time output if there is no time zone indication,
>       per <https://en.wikipedia.org/wiki/ISO_8601#Local_time_(unqualified)>.

Hmm, good to know.  That's what we assumed, but didn't know it for sure.

>     - 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."

We have sooo many problems together.  :-)

Have a lovely day!
Alex

> Bruno

-- 
<https://www.alejandro-colomar.es/>

signature.asc
Description: PGP signature