Re: [PATCH v3] ctime.3: EXAMPLES: Add example program

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Fri, 23 Aug 2024 19:48:09 +0200
    From:        Alejandro Colomar <alx@kernel.org>
    Message-ID:  <cb65drmcb6cotrz6rzkfuwg5aod2jta4ma6f6cds4pouk5tjdj@6wl6iwby2isi>

I kind of suspect there has been some discussion I am not privy to
preceding this, so if anything I add here seems redundant, or whatever,
that's why.

  | (Although I'm not sure if that mailing list is open.  maybe it rejects
  |  mail from this account.  Please anyone bounce it if you find that it
  |  doesn't reach the list.)

Same here.  I am fairly sure (since I have received no recent messages)
that I got dropped from the austin list during a period when munnari.oz.au
was reachable only via IPv6 (something of an experiment, though the
original reasoning was different).    It appears that the austin-group
mailing list is only able to transmit mail via IPv4.   Shame.

Also note that I removed "Robert C. Seacord" <rcseacord@gmail.com>
from the recipient list, as gmail continue to refuse to receive mail
from munnari - there was no point attempting that one.   Someone can
forward if that seems called for.


  | > and which implementations have been checked.
  | Robert, Geoff, Andrew, can you please clarify?

Me, no, sorry, that is something from the linux world I think.

I actually have no idea whether our implementation (Paul might be
able to guess, since this is unlikely to have been changed from tzcode)
whether our implementation alters tm_wday in various failure cases or
not.

  | Robert, Geoff, Andrew, can you please clarify where is the discussion
  | that led to the following change?:

There were a lot of discussions about mtime() - lots of it on the list,
some of it in the mantis defect report database (associated with more than
one bug), and more about strftime("%s") which is almost the same thing.

Sorry, I can't point you at anything in particular which led to that.

  | You could argue with them that there's no way to test for errors other
  | than this method,

That's probably a reasonable summary of the rationale.

  | I guess if a weekday was ever added,

If there's anything about the management of times less likely to happen
than that one, I cannot imagine it.   Weeks with fewer days are possible,
in bizarre circumstances (like when Gregorian time became standard) but
not ones with more.   It would be more likely that the concept of a week,
and weekday names, would be eliminated, than a new day be added.

Adding months would be a far more likely thing to happen - after all,
that's happened before.

Of course, if the whole way of measuring time were to be changed, then
almost anything might appear as a replacement.   mktime() wouldn't apply.

kre