[Bug libc/11620] Bad design of timezone conversions

["maxim.yegorushkin at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=11620

--- Comment #3 from Maxim Yegorushkin <maxim.yegorushkin at gmail dot com> 2012-11-08 23:57:21 UTC ---
I just wanted to expand on what I said earlier because I really believe this
would be a major improvement in timezone handling.

Ulrich mentioned that "There is absolutely no reason whatsoever that any such
set
of interfaces have to be in the C library.". It seems to me that for this
argument to be valid there should not be examples to the contrary. 

There is a standard C library function gmtime(). There is no reverse function
for it in the C standard. People often ask for the reverse of this function and
a quick google search for "gmtime reverse" retrieves around 1.3e6 hits, as of
today. Yet, glibc does provide a reverse of it, timegm(), a more than just a
useful function judging from the number of the web search hits. 

This example appears to contradict Ulrich's statement that was used as a
justification for closing this request. It feels like the reasoning for closing
this ticket was less than perfect and I felt compelled to re-open it. 

I looked at the sources of glibc today and it looks like __tzfile_read() loads
an entire Olson database into memory. This database allows conversion from any
timezone to UTC and back. Glibc provides functions for converting back and
forth between UTC and the current local timezone only. To complete the picture,
there is a "solution" mentioned in NOTES of man timegm, that involves changing
TZ environment variable to temporarily switch the local timezone to another one
to force mktime() convert struct tm expressed in that other timezone into a
time_t. This solution doesn't feel quite satisfactory and it is not thread-safe
(unless one explicitly holds a mutex while changing TZ environment variable
everywhere in the code, which may be harder to achieve in the presence of
3rd-party libraries without the source code).

To summarize, the Olson timezone database has always been in glibc's memory,
but applications haven't been able to fully utilize that, or at least, without
that verbose and unreliable code, which also doesn't seem to be a common
knowledge.

I would propose adding a couple of functions to fill this gap:

    time_t time_tz_to_utc(<timezone> tz, struct tm* from);
    struct tm* time_utc_to_tz(<timezone> tz, time_t);

The first function would convert a broken-down time expressed in timezone tz
into time_t (which is the number of seconds since UTC epoch).

The second function would do the opposite.

<timezone> should probably be a pointer to a structure, rather than a timezone
string, e.g. "Europe/Paris", to avoid string look-ups on each call. E.g.:

    typedef struct __Timezone* timezone_t;
    timezone_t time_find_timezone(char const* olson_tz_name);
    void time_release_timezone(timezone_t);

I remember reading other proposals to evolve the C standard library time
functions, but can't find it right now. It may provide more well-thought
interfaces. But, I think, for the majority of us this would be a major step
forward.

-- Maxim

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.