C/C++ library that parses TZ data?

[Guy Harris]

On Feb 9, 2011, at 8:23 AM, Olson, Arthur David (NIH/NCI) [E] wrote:

> Since the zoneinfo data is present in every Unix system

(Well, actually, I'm not sure HP-UX has it; they had their own scheme for handling other time zones.  Perhaps they've switched to zoneinfo recently.  Some older UN*Xes didn't use zoneinfo, e.g. pre-SVR4 System V from AT&T.)

> and glibc includes
> routines for parsing it, interfacing with glibc seemed the obvious solution.
> Unfortunately, glibc was not designed with this use case in mind.

For better or worse, the use case for which glibc's interface was designed was the "compatibility with the API that's been in UNIX since time immemorial" use case.  The UNIX APIs - localtime() and mktime() - are pretty good for the "what time is it in my time zone?" use case (although it, alas, took entirely too long for mktime() to become part of that API; the tz code might have pushed it in that direction).  For the "what time is it in an arbitrary time zone" use case, not so much; back in the 1970's, when the UNIX API was first created, that was perhaps a less common case.  As the person who submitted the bug you cite said, "This is design of the pre-internet era." - and, in fact, localtime() and company were designed not just in the pre-Internet era, but in the pre-TCP/IP era (RFCs 791 and 793 have dates in September 1981).

Has any consensus been reached on the proposal in the "Extension to tzcode to support additional timezones" thread?  If we provide APIs to handle time conversions for multiple time zones in the same process in our sample code, that might encourage those OSes whose time conversion routines are based on our sample code to pick up our implementations and possibly encourage those OSes whose time conversion routines aren't based on our sample code (e.g., anybody who uses glibc) to pick up the APIs.  There were some open issues that don't seem to have been completely resolved.

> In fact, the glibc interface to zoneinfo can be described as "sui generis" if one
> is feeling charitable,

Well, given that OSes with the same interface include, err, umm, Solaris, HP-UX, AIX, *BSD, Tru64 UNIX, and Mac OS X, in addition to most Linux distributions (and a bunch of older UNIXes no longer with us or no longer being further developed), and all of them, with the exception of the Linux distributions, not using glibc, I don't think "sui generis" is accurate - the glibc APIs are not unique to glibc, they're just doing what every other UN*X is doing.

> or "insane" if truth must be told.

I think "not at all useful for an operation that many applications require" would be more accurate; it works well for the use case for which it was intended, but it's a bit craptastic for anybody who cares about other time zones, and there are a number of developers like that out there.

> The abbreviated name of the timezone can be found in the global 'tzname'
> array: at position 'tzname[0]' if daylight savings are not in effect and at
> position 'tzname[1]' if they are.

Well, that particular AT&T invention was a bit suboptimal - it's hostile even to applications that only care about one time zone but that are converting times in more than one thread, but, well, it was concocted before multi-threading support was very common in UN*X, so it was more of a case of not being very future-proof than being completely crazy.

But, in any case, yes, an API that better handles that case would be nice.