From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2007-02-27 09:22:08
On Mon, 26 Feb 2007 21:46:33 -0700
Jeff Garland <jeff_at_[hidden]> wrote:
Thanks for you response to this issue!
> > Specifically, I use boost 1.33.1, as released. What do I have to do
> > in order to use Boost.DataTime appropriately in light of the new US
> > DST changes?
> Unfortunately, the answer is, it depends. There are multiple features
> in the library to help calculate dst -- can you share precisely *how*
> you are calculating dst?
It looks like most of our code uses the "deprecated" feature since it
was written several years ago. We also have some code that uses the
> Yes, it does. If you are using the tz_database you will need to
> install the new version of the 'date_time_zonespec.csv' file. It's
> in the vault at:
I assume that will help for the "lookup" method. Are there any new
> If you are using the dst_calc_engine or one of the 'deprecated' static
> calculation functions you will need a code update. I'm putting the
> final changes on these updates now. Some of the static methods will
> actually support historic times although their interfaces had to
> change. I'll try to post a summary and patches for 1.33 after I'm
Any idea when it will be ready and available? We use this code in
production systems, and we are running out of time to implement, test,
and deploy. We have two "emergency" strategies, that we will have to
implement very soon otherwise.
> > Basically, I want to know what changes I need to make to my programs
> > and/or libraries that use Boost.DateTime aside from the glibc
> > update?
> glibc won't have an impact on date-time...so you'll have to do
> something more.
>From what our IT guys tell me, there is a glibc rpm that includes the
timezone file and possibly other stuff. Any code that uses the
"standard" interfaces should work with the update (we are in the process
of updating hundreds of machines with that one). However, I am
concerned about the boost datetime stuff as well.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk