C/C++ library that parses TZ data?

[Dario Teixeira]

Hi,

> (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.)

I meant "Unix" as in "most popular Desktop Unixen"...


> 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).

Yes, I realise there's a huge historical baggage associated with the current API,
not to mention a POSIX mandate.


> 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.

Indeed, I've noted that glibc and other projects use essentially your code
for tzcode handling, so if you were to make those API additions, there's
a better chance it would be also picked up downstream.  Nevertheless, the
attitude expressed by the glibc maintainer in the bug report I mentioned
does not bode well for frictionless communication [1]...


> 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.

I singled out glibc when perhaps blaming POSIX might have been more correct.


> 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.

Though slightly hyperbolic as my rethoric may have been, the truth is that
this is 2011, and there have been for many years now tangible drawbacks to the
antiquated API in glibc and its counterparts.  Most notably is that anyone
who needs a functional interface to the tzcode routines (ie, one which does
not require mutating global state) needs to copy & paste & adapt the code.
This sort of code replication is inefficient and potentially dangerous if
a security vulnerability is found (instead of trusting a single update from
glibc you have to hope all the projects using the code will fix the same flaw).

As for what that API should look like, there are essentially three requirements:

1) Keep the existing API for backwards compatibility.

2) A hypothetical 'timezonetime' function which takes as parameter a timestamp
   and a timezone should be truly functional in the sense of not having
   side-effects nor requiring pre-setting some global environment variable.

3) The API should cater for optimised conversion.  This means that the caller
   should have the option of keeping a cache of parsed zoneinfo files, and
   the invocation of 'timezoneinfo' can be given one of these.  For example:
   (in pseudo-code)

   zninfo = parsezoneinfo ('Europe/Lisbon');
   time_str = timezonetime (zninfo, current_time);


Thanks again for your attention!
Best regards,
Dario

[1] http://sources.redhat.com/bugzilla/show_bug.cgi?id=11620