Re: date without time

[Alejandro Colomar]

Hi Serge,

On Fri, Aug 02, 2024 at 01:47:40PM GMT, Alejandro Colomar wrote:
> 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.

This morning I've been thinking about this process.  If we go back and
forth from local=>UTC=>local, we're doing the following:

CEST    |--------- 20 ---------|*--------- 21 ---------|
UTC       *--------- 20 ---------||--------- 21 ---------|
CEST    *--------- 20 ---------||--------- 21 ---------|

We've lost a day.

I've remembered about <https://github.com/shadow-maint/shadow/pull/942>.
And now I see why they added the half day.  They assumed dates were
introduced with day precision, and wanted the second in the middle of
the day to minimize that drift.  It was incorrect, though, since the
dates parsed by get_date() have second precision (it can parse date/time
strings).  So, we need to lose that day, or at least the 22 hours;
there's no way to avoid it.


On the other hand, considering that what is actually stored in
/etc/shadow, and thus what is actually used for comparison with dates
for deciding if a login is valid or not, is the UTC timestamp, I think
we should print them as UTC timestamps.  Otherwise, we're lying.  Since
second-precision timestamps have (most of the time?) a 1:1
correspondence with a local time, it makes sense to translate UTC
second-precision timestamps to local time.  That is, there's no added
error in the translation.  However, when translating day-precision UTC
timestamps to local time, more error is added (you cannot convert back
to UTC lossless.  Thus, I think we should print day-precision timestamps
in the same timezone that they're stored (UTC).

I thus propose reverting
<https://github.com/shadow-maint/shadow/pull/1058>, and instead append a
Z after the date, to mark it as a UTC timestamp.

Does it make sense?

Have a lovely day!
Alex

> >     - 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/>



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

signature.asc
Description: PGP signature