Robert Elz <k...@munnari.oz.au> wrote: > Date: Sat, 22 Oct 2022 13:42:54 -0400 > From: Jan Schaumann <jscha...@netmeister.org> > Message-ID: <y1qrnixdev1bn...@netmeister.org> > > | 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