Robert Elz <k...@munnari.oz.au> wrote: > Date: Fri, 21 Oct 2022 10:36:23 -0400 > From: Jan Schaumann <jscha...@netmeister.org> > Message-ID: <Y1KuZ/mcmbcev...@netmeister.org> > > > | 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
