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

Subject: Re: [boost] [date_time] [#1861] Change for the default duration format
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-06-15 11:42:18

Andrey Semashev wrote
On Monday, June 01, 2009 7:01 PM
> On Tuesday 02 June 2009 00:56:53 Stewart, Robert wrote:

I missed your message previously, hence the long delay in replying.

> > > > 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.

strftime() is used as the basis for the conversions and is the obvious source of the meaning of the various format specifiers.  Consequently, it remains a viable exemplar of expected behavior.

Having said that, I recognize your point about time durations versus time points.  If the suggested change only applies to time durations and not to time points, of which I have no idea, I'd be much less concerned.

> > > 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.

We're obviously speaking of new code.  You haven't justified assertion only.

> 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.

Sorry, but no.  The default is for IOStreams to set the stream state to indicate failures, but that doesn't absorb exceptions from code such as we're discussing and convert exceptions into stream state.

> 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.

A well designed library prevents misuse.  That's an argument for changing the default formatting, I grant.  It's also an argument for throwing an exception rather than silently truncating if the default formatting isn't changed for other reasons.  Yes, folks must use libraries correctly.  In C libraries, the functions return error codes which can be ignored.  In C++, we have exceptions at our disposal.  Furthermore, there are many developers who don't spend much time with debug builds and there are many usage scenarios that can arise untested.  The library shouldn't misbehave silently in those cases.

> > > 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.

Every online strftime manpage I checked, such as the following, describes %O:

http://www.opengroup.org/onlinepubs/007908799/xsh/strftime.html

> > 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.

In my mind, that justifies my trying to map to strftime() behavior.

> > 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.

Hmmm.  I didn't realize that DateTime already used %O for this purpose.  That is a significant argument in favor of using %O, but perhaps my comments in this thread will convince Jeff that he should take another tack.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.