Michael Caisse wrote:

Jeff Garland wrote:

...

glibc won't have an impact on date-time...so you'll have to do something more.

One more little detail. Canada has also changed DST rules to match the new US rules. Mexico did not. So it's really a North American DST rule update not just a US change.

Jeff

Not to be too picky, but Mexico is part of North America.

Right, sorry. Well anyway, Canada's switching -- Mexico isn't. Jeff

Jody Hagins wrote:

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.

I don't know what the 'lookup' method is -- does it use the 'tz_database' class? Code should look something like this: tz_database tz_db; tz_db.load_from_file("date_time_zonespec.csv"); time_zone_ptr nyc_tz = tz_db.time_zone_from_region("America/New_York");

...

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?

Yes, some of the tests changed -- these are already change in CVS. Basically the only change was to libs/date_time/test/local_time/testtz_database.cpp

...

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.

Probably today, but I'm likely won't have time to test against 1.33.1 -- only 1.34. But I think the code will be backward compatible.

...

...

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

Boost date-time doesn't directly use the glibc timezone data on *nix because it's not portable to windows. Likewise, it doesn't use the Windows based timezone data via the windows api because it's not portable to other platforms. The only thing these rpm patches might impact would be calls to the various clock lookup functions which can either return 'local_time' or 'utc_time'. Calls to these functions use posix C functions and the machine settings impact the results. Specifically, after the transition to DST the calls to local_time should return correctly adjusted times. Anyway, my original statement about there being no-impact on Boost date-time was a bit mis-leading. You clearly need to maintain the machine setup.

However, I am concerned about the boost datetime stuff as well.

As you should be. Jeff