Jody Hagins wrote:
I understand this topic has been discussed several times, but I am unable to find a clear, authoritative indication as to the current status of the library.
Sorry to be so slow and difficult about this :-(
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?
Currently, my list includes applying the RPM update for glibc to all my linux boxes. Do I need to do anything else? Earlier emails made me think that DateTime uses an independent mechanism for applying timezone information. Is this true?
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 Please be aware that when you install this file if you use it to calculate times prior to 2007 it will be in error because it does not support historical timezone data. 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.
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. 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