[tz] CCTZ time zone library for C++ from Google
andrew at ishiboo.com
Wed Oct 28 20:09:28 UTC 2015
If you're interested in keeping up with C++ APIs, check out ours as well:
It is built atop date/time types (John Lakos designed) in a lower package.
bdlt::Datetime (no offset/tz), bdlt::DatetimeTz (datetime + offset), and
baltzo::LocalDatetime (datetime + iana tz string) to cover all the use
cases. The baltzo package allows efficient conversion from one timezone to
another using these types. Included in the package is a default
process-wide cache to help speed everything up.
baltzo::TimeZoneUtil contains the high level conversion routines:
Feedback always welcome :)
On Wed, Oct 28, 2015 at 1:12 PM, Matt Johnson <mj1856 at hotmail.com> wrote:
> I for one am happy to see progress made WRT time zone APIs in the C++
> world. cctz may not be entirely comprehensive (like the new Java 8
> date/time api, etc.) , but it does what it does quite well.
> From: mj1856 at hotmail.com
> To: brian.inglis at systematicsw.ab.ca; tz at iana.org
> Subject: RE: [tz] CCTZ time zone library for C++ from Google
> Date: Wed, 28 Oct 2015 10:10:10 -0700
> 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.
> > To: tz at iana.org
> > From: Brian.Inglis at 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 <
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz