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-15 17:23:50

On Monday 15 June 2009 19:42:18 Stewart, Robert wrote:

[snip]

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

Exactly, I'm speaking of durations only. Time points won't be affected.

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

It does adsorb exceptions, at least on my GCC 4.3.2. But it does pass through 
original exceptions if exceptions are enabled, but I'm not sure it's 
guaranteed by the standard. You can play with the attached code sample to test 
your platform.

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

Right. But since DateTime IO is based on facets, there isn't much room for 
design decisions. As for the exception, it does not prevent misuse. It *may* 
show when the feature *have been* misused.

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

We can debate on this. There are people that prefer safety at all costs. There 
are other people, including me, that don't want to pay for unnecessary run 
time checks. My position is that there are no guarantees if the code is used 
incorrectly. If I want safety, I do the proper testing, including debug builds 
and invalid input to my system to verify that it tackles it well. One 
advantage of the assert is that it can satisfy both safety and performance 
needs.

> > 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 guess, %O was not a good choice in the first place, then. I'm not inclined 
to change it now, but the final call is after the library maintainer.

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

I'd consider strftime as an implementation detail.