On Tue, Oct 25, 2022 at 02:56:23PM +0700, Robert Elz wrote:
> I am not sure that calling strftime() on something obtained from gmtime()
> makes any sense. If one wants UTC conversions, either use strftime_z()
> (not a POSIX interface) or set the timezone to UTC (tzset() with TZ="UTC").
Where i
> When %s was added to strftime() it was done by simply calling
> mktime(). I don't know who originally did that, but that's what
> happened, and after that the interface was simply copied. [...]
> [...redesign...]
> But doing that in a way that's agreeable to everyone, and then
> getting it act
On Tue, Oct 25, 2022 at 23:07:56 +0700, Robert Elz wrote:
> The standard is going to (as it should) say what works now, and what
> applications and users can expect. In this case it is that
> strftime("%s") gives the same thing as printf("%ld", mktime())
> when applied to the same tm.
[...]
> Th
Date:Tue, 25 Oct 2022 16:11:48 +0300
From:Valery Ushakov
Message-ID:
| I'm not very familiar with the lore of this API, but my guess was that
| strftime(3) was specified the way it was b/c TZ info (except for
| tm_isdst) was not the official part of struct tm -
On Tue, Oct 25, 2022 at 14:56:23 +0700, Robert Elz wrote:
> Date:Tue, 25 Oct 2022 04:08:13 +0300
> From:Valery Ushakov
> Message-ID:
>
> | strftime(3) %s format is not in ISO C or POSIX, though the rumor is
> | that it will be in the next POSIX version.
>
> It
Date:Tue, 25 Oct 2022 04:08:13 +0300
From:Valery Ushakov
Message-ID:
| strftime(3) %s format is not in ISO C or POSIX, though the rumor is
| that it will be in the next POSIX version.
It will be. The text is:
sReplaced by the number of seconds since the E
