Re: CVS commit: src/lib/libc/time

[Jan Schaumann <jschauma%netmeister.org@localhost>]

Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
>     Date:        Sat, 22 Oct 2022 13:42:54 -0400
>     From:        Jan Schaumann <jschauma%netmeister.org@localhost>
>     Message-ID:  <Y1QrnixDev1BN99Y%netmeister.org@localhost>
> 
>   | A full set of examples strikes me as too much here
> 
> A full set would be yes, but I think we could handle 3.

Hmm, maybe something like this?

----
...and will be normalized, if need be.

For example, consider a struct tm initialized with a
tm_year = 122, tm_mon = 11, tm_mday = 30, tm_hour =
22, tm_min = 57, and a tm_sec = 0, using UTC,
representing 2022‐12‐31T22:57:00Z.  Incrementing
tm_min by 13 and calling mktime() would yield a time_t
with value 1672528200, representing
2022‐12‐31T23:10:00Z, as the tm_min = 70 was
normalized to an increment of tm_hour by one and
tm_min = 10.

This normalizing can lead to cascading changes: Again
using a struct tm initialized as in the above example
but with a tm_hour = 23, the same change would yield a
time_t with value 1672531800, representing
2023‐01‐01T00:10:00Z: the normalization of tm_min
incremented tm_hour, which lead to a normalization
of tm_mday, which in turn caused tm_mon to be
normalized, which in turn lead to the increment of
tm_year.

In addition, negative values may also be normalized,
such that e.g., a tm_hour of −1 means 1 hour before
midnight, tm_mday of 0 means the day preceding the
current month, and tm_mon of −2 means 2 months before
January of tm_year.
---

The fact that mktime(2) returns a time_t makes the
phrasing even more awkward, and I suppose we could
leave out the actual value and say "would yield a
time_t representing..."?

Other ideas to improve this?

-Jan