[tz] strftime %s
Steffen Nurpmeso
steffen at sdaoden.eu
Sat Jan 13 22:27:57 UTC 2024
Brooks Harris via tz wrote in
<39dd1363-5618-42b6-b0cc-02f5dbc06750 at edlmax.com>:
|On 1/13/2024 12:00 AM, Robert Elz via tz wrote:
|> Date: Fri, 12 Jan 2024 14:47:02 -0500
|> From: scs at eskimo.com (Steve Summit)
|> Message-ID: <2024Jan12.1447.scs.0002 at tanqueray.local>
...
|> time_t (in C) has a largely unspecified format and reesolution.
|> The only portable way to do arithmetic (perhaps even comparisons,
...
|I like Steve's idea of including a tm_time_t member in struct tm. I use
|something like this in my internal processes.
...
|I'm not sure how feasible it is but perhaps the Posix folks might
|consider the idea.
I cannot speak for them, but Robert Elz has brought up the idea of
an entirely new interface, and i personally think that *if*
anything would be done, then it should be a real object based
approach.
Something "datetime" alike, what many scripting+ languages and
libraries offer, with defined arithmetic, most often with
dedicated functions like add_months|years|days|microseconds, what
do i know. Ie no more +1900 at time, no more such things, but
accessors and questions onto an object interface that does not
modify global data. That would surely be a good new foundation.
And then there needs to be some calendar object to be able to
truly reflect cultural date and time differences. I never was
able (nor did i have the need) to work with these real things.
It is hard to imagine that ISO C does anything such.
--End of <39dd1363-5618-42b6-b0cc-02f5dbc06750 at edlmax.com>
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
More information about the tz
mailing list