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

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

Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
>     Date:        Fri, 21 Oct 2022 10:36:23 -0400
>     From:        Jan Schaumann <jschauma%netmeister.org@localhost>
>     Message-ID:  <Y1KuZ/McMBCevcQR%netmeister.org@localhost>
> 
> 
>   | Perhaps like this?
> 
> Like that, yes, but as you wrote it isn't how it is actually
> done I believe.
> 
> The order looks to be secs, mins, hours, month, day(of month).
> 
> There's no normalisation of the year (no invalid values to correct)
> though the year can be adjusted when the month is adjusted.
> 
> That order is assuming that the system is using posix stretchy seconds,
> rather than UTC (with leap seconds), but almost all NetBSD systems
> work that way - if UTC is being used, then secs cannot be done first,
> as until the rest of the data/time is known, it is unknown whether
> the number of seconds permitted is 59 60 or 61.   With POSIX seconds
> the secs/mins/hours correction order doesn't really matter, as there
> are always 0..59 secs, 0..59 mins, and 0..23 hours, the rest of the
> fields have no impact at all.

Right, but all that strikes me as too much to put into
the manual page here.  I think what matters in this
context is that there is an order and that there is a
cascading effect.

"This normalization is done in order from tm_sec to
tm_mon (inclusive), possibly leading to cascading
values."

or

"This normalization is done in order from tm_sec up to
tm_year, possibly leading to cascading values."

provides sufficient information, I think?

-Jan