Hi Guy, On 24/9/22 17:27, Guy Harris wrote:
This appears to be more of "faster implementation of mtkime()" than "direct implementation of mtkime_z()", as the bulk of what you're talking about appears to be a faster way of converting a struct tm into a time_t rather than adding support for having a routine that can convert a struct tm, in an *arbitrary* tzdb region rather has the current tzdb region, to a time_t. The two are independent - the "convert a struct tm, representing local time in a given tzdb region, to a time_t" part is orthogonal to the "is the given tzdb region the default region for the process, or is it an arbitrary region specified by a handle?"
That's right, I'm talking about a faster way to convert a struct tm to a time_t. Perhaps "direct" was a poor choice of word; I was trying to distinguish between the "binary search the time_t range" approach, which is arguably an indirect way to perform the calculation, to an approach where the time_t is calculated with a bunch of algebra and whatnot. I can see how my mention of mktime_z could be interpreted to mean what you say. Apologies for the sloppy subject.
For the latter, one issue si "what's the appropriate time zone name abbreviation for that particular time, and, if there's a way to 'close' a handle for a tzdb region, then, if there's a call that provides a string for that abbreviation, does that string survive closing the handle for the region?"
Indeed, the fact that tm_zone is a pointer is a frustrating part of struct tm, but it's not one I'm attempting to address. -Ted