Opened 13 years ago

Closed 13 years ago

#3126 closed Bugs (duplicate)

boost::format in debug build is no longer able to format time_duration with hours >= 100, as of svn rev 49874

Reported by: mbd@… Owned by: Samuel Krempp
Milestone: Boost 1.40.0 Component: date_time
Version: Boost 1.38.0 Severity: Problem
Keywords: format time_duration Cc: Samuel.Krempp@…

Description

https://svn.boost.org/trac/boost/changeset/49874 breaks boost::format's ability to format a time_duration if it has more than 99 hours.

It is unclear from the docs whether this is intended behaviour or not. I believe it is because boost::format uses the default time_facet format of "%H:%M:%S%F". Had it been using "%O:%M:%S%F", I think there would have been no breakage(?)

The attached minimal program illustrates the problem.

Attachments (1)

main.cpp (723 bytes ) - added by mbd@… 13 years ago.
Minimal program that illustrates problems when formatting a time_duration with more than 99 hours. Make sure to use a debug build of boost to get an assertion.

Download all attachments as: .zip

Change History (5)

by mbd@…, 13 years ago

Attachment: main.cpp added

Minimal program that illustrates problems when formatting a time_duration with more than 99 hours. Make sure to use a debug build of boost to get an assertion.

comment:1 by Samuel Krempp, 13 years ago

Cc: Samuel.Krempp@… added
Component: formatdate_time
Resolution: invalid
Severity: ProblemNot Applicable
Status: newclosed

boost::format only forwards to iostream without any specific handling, the issue is thus about date_time's output operators - or that behavious is intended.

If you do not specify the desired formatting through the locale (see http://www.boost.org/doc/libs/1_40_0/doc/html/date_time/date_time_io.html) and set boost::format to use it, then boost::format simply use default locale.

I am not familiar with boost::date_time but assumes the assertion in the attached case is intended.

comment:2 by mbd@…, 13 years ago

In fact, I think it would be more appropiate to file this as a duplicate of issue 1861, which appears to have been resolved 6 weeks ago. I have yet to check.

As 1861 indicates, this is (was) a real issue. I am not certain that 1861 *does* fix this issue, but if not, I actually believe that this issue should be resolved.

Regards

comment:3 by Samuel Krempp, 13 years ago

Resolution: invalid
Severity: Not ApplicableProblem
Status: closedreopened

You're right, I'll reopen it just to mark it correctly

comment:4 by Samuel Krempp, 13 years ago

Resolution: duplicate
Status: reopenedclosed

duplicate of #1861 (which is fixed)

Note: See TracTickets for help on using tickets.