Brooks Harris via tz wrote in <39dd1363-5618-42b6-b0cc-02f5dbc06750@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@eskimo.com (Steve Summit) |> Message-ID: <2024Jan12.1447.scs.0002@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@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)