[tz] strftime %s

[Brooks Harris]

On 1/13/2024 4:09 PM, Guy Harris wrote:
> 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?

mktime() would set it regardless. I doesn't need to know prior state 
since its calculating from the broken-down-time.
>
>> 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.)
Yes. I use things like that to flag if my app has initialized some 
variable to some default value. But, yes, it doesn't really flag "is 
valid now". The app has to keep track of that.
>
> This all sounds like a lot of complication for *not* a lot of benefit;
Seems to me the benefit is keeping the tm_time_t value coupled to the 
broke-down-time. Localtime() can set that so a call to mktime() isn't 
needed.
> 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?
It not so much about mktime() as localtime().
>
>> 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,
It's not about speeding mktime() but keeping the tm_time_t value coupled 
to broken-down-time in many instances instances of struct tm.
> 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.
>
localtime() sets it, and mktime() sets it. Whichever last called has set it.

Well, I think its a good idea. I find it simplifies many operations.

But timekeeping takes time, we've been at it for 2500 years. :-)