From: Jeff Garland (jeff_at_[hidden])
Date: 2007-02-27 09:59:09
Jody Hagins wrote:
> 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
> "lookup" method.
I don't know what the 'lookup' method is -- does it use the 'tz_database'
class? Code should look something like this:
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:
> I assume that will help for the "lookup" method. Are there any new
Yes, some of the tests changed -- these are already change in CVS. Basically
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
> 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
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk