[1.33.0][date_time] Yr 1900 issue on x64 Win
I'm trying to use Boost 1.33 libs on x64 Windows platform. Have assert break when try to use date below year 1900. Is it known issue? To reproduce: #include "stdafx.h" #include <iostream> #include <boost/date_time/local_time/local_time.hpp> int _tmain(int argc, _TCHAR* argv[]) { using namespace boost::gregorian; using namespace std; date d(1899, Jan, 1); stringstream ss; ss << d; cout << ss << endl; return 0; } The cause located in conversion.hpp module and strftime() assert : boost::gregorian::date::ymd_type ymd = d.year_month_day(); datetm.tm_year = ymd.year-1900; _VALIDATE_RETURN( ( timeptr->tm_year >=0 ), EINVAL, FALSE) Thanks, Dmitry Solodkiy, SW engineer
On 12/6/05, Norian N <noriann@gmail.com> wrote:
I'm trying to use Boost 1.33 libs on x64 Windows platform. Have assert break when try to use date below year 1900.
_VALIDATE_RETURN( ( timeptr->tm_year >=0 ), EINVAL, FALSE)
This is an issue with the Microsoft runtime libraries and not the fault of Boost.DateTime. There is absolutely no good reason for this check (IMHO). There is nothing in the strftime code (aside from these debugging assertions) that would fail on years prior to 1900, yet these assertions exist. I really wish they would remove them. -- Caleb Epstein caleb dot epstein at gmail dot com
On Tue, 6 Dec 2005 15:55:15 -0500, Caleb Epstein wrote
On 12/6/05, Norian N <noriann@gmail.com> wrote:
I'm trying to use Boost 1.33 libs on x64 Windows platform. Have assert break when try to use date below year 1900.
_VALIDATE_RETURN( ( timeptr->tm_year >=0 ), EINVAL, FALSE)
This is an issue with the Microsoft runtime libraries and not the fault of Boost.DateTime.
There is absolutely no good reason for this check (IMHO). There is nothing in the strftime code (aside from these debugging assertions) that would fail on years prior to 1900, yet these assertions exist. I really wish they would remove them.
I have to agree with this. This is a result of recent MS changes that now break code that works on many other platforms and previously worked on MS platforms. I suppose someone ought to submit formal bug reports to complain. Only problem is AFAIK there is no C/C++ specification that says whether negative values are allowed, so perhaps we need a LWG bug report to change the standard. The whole reason we need to do this is so that we can send a tm value into the standard facet for formatting. This makes working around the problem in a generic way very difficult. So unfortunately, you might need to consider using to_string or writing your own printing function if you are using this particular platform. I suppose we are going to have to add more portability notes as well....sigh.... Jeff
participants (3)
-
Caleb Epstein -
Jeff Garland -
Norian N