Mark Van Dijk wrote:
My apologies for not specifing this earlier - i just assumed that many people had previously run into it. Michael Mathews is correct about the operator<<() and strftime.c being the cause of this issue.
Thx for the detail. I don't normally develop on Windows -- unless I'm paid that is ;-)
operator<<(ostream&, time_duration const&) basically converts the time_duration object to a tm struct using the function boost::posix_time::to_tm(time_duration const&). At this point, the tm structure contains an hours value of 24 - which Microsoft considers to be out-of-range. Further down the stack the _Strftime_l() function verifies the tm structure and everything comes to a crashing halt at this point.
Yeah that clears up the mystery.
The MSDN docs for _Strftime_l() states that this function will check the tm struct for invalid and out-of-range values and will call the invalid parameter handler in this case.
Hope that helps :-)
While my initial reaction is that I'm not inclined to fix this problem since this seems like another case of an over-zealous 'safety cleanup' on MS part (The previous example was when MS disallowed tm from having negative years early in VC8 -- thus not correctly handling output for any date less than 1/1/1900 breaking working code - someone submitted a bug report and I believe they've changed it back now). Anyway, on my Linux machine with gcc4 things operate pretty much does what you might expect: time_duration td1(300,0,0); std::cout << td1 << std::endl; 300:00:00 That said, I am compelled by the open group spec for strftime saying that %H has a range of 00-23. So this seems like an ugly specification flaw in the date-time i/o concept for durations. Basically a really nasty problem for long time durations that depend on output of larger than 2 digit hours quantities. The quick hack would be to change time_facet.hpp to override the %H output. However, %H input is also broken because it only looks for 2 digits. So, I'm afraid this isn't a super quick issue to resolve... Note I'm guessing the reason this doesn't come up to much is that most people use time_duration output in the context of ptime which normalizes the day count on construction: date d(...); ptime t(d, hours(24)); //d+1 at 00:00::00 std::cout << t << std::endl; //fine...hours will be 0 Jeff