Could be worse.  Could be like the Boost date_time api, which somehow thought it would be acceptable to map tzdb identifiers to fixed offset pairs, and never even bothered to keep them updated.
http://www.boost.org/doc/libs/1_59_0/doc/html/date_time/local_time.html#date_time.local_time.tz_database
https://github.com/boostorg/date_time/tree/master/data

T

> To: tz@iana.org
> From: Brian.Inglis@systematicsw.ab.ca
> Date: Wed, 28 Oct 2015 09:52:32 -0600
> Subject: Re: [tz] CCTZ time zone library for C++ from Google
>
> On 2015-10-21 13:34, Tim Parenti wrote:
> > FYI, last month, Google released and open-sourced cctz <https://github.com/google/cctz>, a new time zone library for C++.
> >
> > My favorite quote from the announcement <http://google-opensource.blogspot.com/2015/09/introducing-cctz-simple-time-zone.html> on their Open Source Blog:
> >
> > /"Time zones are logical and easy to use." —no one ever/
>
> Don't think that project will help much, as the zone is not part of the opaque structure, but is a separate parameter in their API: that won't cause many problems! ;^>
> If we think back 15+ years, many problems were due to messing around with sub-chunks of dates, whether string, integer, or bits, instead of using the APIs provided to convert from one date representation to another. Is it September again in the date/time domain?
>
> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada