On 24/12/2023 01:09, Jeffrey Walton wrote:
On Sat, Dec 23, 2023 at 11:56 AM Max Nikulin wrote:
(info "(libc) Broken-down Time")
https://www.gnu.org/software/libc/manual/html_node/Broken_002ddown-Time.html#index-mktime
The ‘mktime’ function ignores the specified contents of the
‘tm_wday’, ‘tm_yday’, ‘tm_gmtoff’, and ‘tm_zone’ members of the
---------------------------------^^^^^^^^^
broken-down time structure. It uses the values of the other
components to determine the calendar time; it’s permissible for
these components to have unnormalized values outside their normal
ranges. The last thing that ‘mktime’ does is adjust the components
of the BROKENTIME structure, including the members that were
initially ignored.
So before calling mktime you need to set a timezone having offset of
-0800. I have not figured out if the following approach may give
incorrect results for some corner cases:
- save tm_gmtoff from strptime results
- set UTC timezone
- call mktime
- adjust result by saved tm_gmtoff
Besides performance penalty due to tzset() I would not call it "nightmare".
Here's what someone on the libc mailing list suggested:
<https://sourceware.org/pipermail/libc-help/2021-February/005657.html>.
I'm not sure why threading broke in Mailman, so the thread could not
be followed. I should have posted it with the original email I sent.
I have seen this response and I have decided that it does not address
your case of explicitly specified time zone offset. Mhonarc or whatever
tool used to publish mailing list archive is known to break threads on
month boundary.
The person offered some sample code, and stated there's no way to
avoid the [thread-unsafe] putenv with TZ.
I do not mind. It makes timezone conversions quite expensive.
Also note that it does not
handle a source timezone string like '15 Jan 2021 01:24:55 -0800
(PST)'. You have to manually set TZ=America/California [?] first. It
is not clear to me why the part of the timezone string "-0800 (PST)"
is discarded when creating the time structure.
I think, mktime must follow POSIX, otherwise it will be a great pitfall.
POSIX has nothing similar to tm_gmtoff. Even when GNU extensions are
available, this field still may be 0. Does it mean that mktime should
ignore timezone specified in TZ or /etc/localtime and perform conversion
in UTC? I am afraid, it is not acceptable. It is explicitly stated in
GNU libc docs and I have quoted it in my message.
You do not need namely region-based timezone. You may use a fixed-offset
zone matching tm_gmtoff. I have outlined another way that uses UTC. In
both cases you have to handle tm_gmtoff explicitly in your code.
I think what C programmers need is a libtz that works as expected. And
it needs to behave exactly like libc so there are no hard to track
down bugs.
If it would behave exactly like libc then it could not handle time zones
in a convenient way. There are several C++ libraries to deal with
timezones. Anyway libc is rather limited in respect to various timestamp
modifications: get start/end of day, add or subtract day/month, etc.
Some projects written in C have their own libraries. I have mentioned
timelib from PHP. It seems, nobody is motivated enough to develop a C
library that would be suitable for other projects.
