> Further, if you have just called localtime() or gmtime() there's no
> point using %s either, you know the time_t value, that's what you
> started with, you can simply print it.
If %s is a code-writing-time constant, yes.
If %s comes from, say, the command line, not so much.
I had no idea, befo
Date:Mon, 31 Oct 2022 17:56:43 +
From:David Holland
Message-ID:
| Yes and no. The number of seconds since the epoch is only one value,
| regardless of timezone.
Don't be absurd. The value depends upon the particular time being
considered. That's the whol
On Mon, Oct 31, 2022 at 07:25:34PM +0700, Robert Elz wrote:
> Date:Sun, 30 Oct 2022 20:27:43 +
> From:David Holland
> Message-ID:
>
> | "%sis replaced by the number of seconds since the Epoch"
>
> Yes, though as has been mentioned before, that's inc
Date:Mon, 31 Oct 2022 09:13:48 -0400 (EDT)
From:Mouse
Message-ID: <202210311313.jaa10...@stone.rodents-montreal.org>
| If %s were documented as printing the number that would be obtained by
| calling mktime() on the struct tm? That would (a) be telling the
| ac
> Making the output of %s be implementation defined or unspecified
> would be the same as the situation we're in now (where %s isn't in
> the current standard at all) and so, what it produces if used is
> simply unspecified.
But it would be documented as doing what it actually does, instead of
bei
Date:Sun, 30 Oct 2022 20:27:43 +
From:David Holland
Message-ID:
| "%sis replaced by the number of seconds since the Epoch"
Yes, though as has been mentioned before, that's incomplete (no matter
what you think should happen here, that isn't enough info to c
On Fri, 28 Oct 2022, Thomas Klausner wrote:
I cleaned up the _OPENBSD_SOURCE defines for X, but we can probably
remove some more in other parts of the tree, I plan to do that but
feel free to beat me to it.
I have:
```
$ egrep -r -- '-D_OPENBSD_SOURCE|#define[[:blank:]]+_OPENBSD_SOURCE' /usr
