[tz] strftime %s

Guy Harris gharris at sonic.net
Sat Jan 13 21:09:31 UTC 2024


On Jan 13, 2024, at 12:39 PM, Brooks Harris <brooks at edlmax.com> wrote:

> On 1/13/2024 3:19 PM, Guy Harris wrote:
> 
>> Given that mktime() cannot determine whether it's been set, this means that mktime() must *always* do the conversion work.
> 
> Only if localtime() hasn't already set it.

Again, how is mktime() to *reliablg* know whether it's been set?  Shall another element be added to the structure, containing a bitset of elements with 0 meaning "not set" and 1 meaning "set"?  And how is mktime() to know that the bitset has correctly been set?

> But applications must be careful to be sure it's set to the current value representing the broken-down-time. Maybe some sort of 'state' flag is needed, like "not set", "set by localtime", "set by mktime()"

And how are you to ensure whether the state flag has been set?  Perhaps an additional state flag, indicating the state of the first state flag?  (I'm sure you can see where that takes you.)

This all sounds like a lot of complication for *not* a lot of benefit; most if not all uses of mktime() are in cases where you *don't* know the time_t because it's never been calculated, so all the work that mktime() does is necessary.  Is memoizing its result in this fashion really going to buy you much?

> So I take it you think providing tm_time_t is not a bad idea, generally?

I'm still unconvinced that it won't create more problems than it solves, at least if it's used for *ANY* purpose other than %s in strftime(), where you are at least somewhat likely to be using a structure either generated by localtime() (which is passed the time_t value as an argument) or processed by mktime() (which can set it to the value it computes).

And, in particular, I think using it to speed up mktime() is a colossally bad idea, given that 1) the majority of calls to mktime() are, as far as I know, calls made in order to *derive* a time_t from a date-and-time-of-day value for which you *don't* already know the time_t and 2) trying to make it possible for mktime() to determine whether tm_time_t has been set is complicated and will end up relying on people writing code carefully *and* probably changing existing code.




More information about the tz mailing list