Re: [boost] [datetime] US DST issues

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:

   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