[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