Re: [boost] [date_time] [#1861] Change for the default duration format

Subject: Re: [boost] [date_time] [#1861] Change for the default duration format
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-06-01 19:01:09

On Tuesday 02 June 2009 00:56:53 Stewart, Robert wrote:

> > > I suspect that's not common -- other than for the OP, perhaps.
> >
> > You think so? I don't know how often it is needed to operate
> > longer durations,
> > but IMHO, objectively there is no such restriction for time
> > durations and the
> > library should not artificially impose one.
>
> Given that strftime() uses %OH is for alternative formats, %H is the norm. 
> Consequently, %H seems an unsurprising and useful default for
> Boost.DateTime, too.

strftime is not designed to handle time durations in the first place, so its 
use as an example to follow is questionable. While 24 hour restriction is 
reasonable for time points, it's not for durations.

> > The change mostly affects formatting. There already is an
> > assert, so users
> > will know if %H is used improperly. The assert is present since 1.38.
>
> I question the use of an assert as that's not going to catch errors in
> runtime values in non-debug builds.

I think an assert is enough for various reasons:
1. %H behavior was there for ages, and I don't want to change it even if it 
means more robust error checking. If it caused problems somewhere before, 
either the code was fixed or no one cares. The added assert doesn't change 
that, it only allows to highlight the error in the new code.
2. An exception is not a good choice to highlight the problem, since in most 
cases it will be swallowed by IO streams. In practice streaming errors (in 
form of failbit or badbit) are often ignored, and Boost.DateTime is an 
example. And ios_base::failure usually isn't as descriptive as what is being 
initially thrown.
3. The caller has to check the arguments. It's the bottom line of both STL and 
most C functions. Extensive error checking may be provided but it should be 
optional. An assert fits perfectly.

> > The question is whether the change to %O as a default is
> > justified enough and
> > how it should be announced better.
>
> Using %O in this way is odd, given the strftime() treatment of %O.

I don't have a C standard on me, but I'm almost sure it doesn't specify %O.

> I
> haven't looked at the implementation, but I assume that DateTime is
> interpreting the specifiers itself.

No, at least, not all of them. In the end it comes down to call to strftime, 
last time I checked.

> If so, there's freedom available, but
> deviating from strftime() will make things more surprising than necessary. 
> strftime() uses %E and %O as modifiers.  Thus, there's precedence for using
> a capital letter for a modifier, but there aren't many from which to choose
> ATM: J, K, L, N, and Q.  From those, I'd suggest L because %LH can be read
> as "long hour."

It's %O already and changing it is not a good idea, IMO. People may rely on it 
already.