On Mon, 26 Feb 2007 21:46:33 -0700 Jeff Garland <jeff@crystalclearsoftware.com> 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 "lookup" method.
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:
http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=date_time
I assume that will help for the "lookup" method. Are there any new tests?
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 done.
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.
Thanks, again!