Boost logo

Boost :

Subject: Re: [boost] [date_time] [#1861] Change for the default duration format
From: Ilya Bobir (ilya.bobir_at_[hidden])
Date: 2009-06-17 06:40:20

Andrey Semashev wrote:
> Ilya Bobir wrote:
>> General
>> -------
>> What is so different about
>> time_duration td;
>> cin >> td;
>> from
>> int v;
>> cin >> v;
>> that makes you discuss an alternative error reporting strategy for the
>> time duration input facet?
> Because apparently not everyone is happy with the current strategy.

If the time period input and/or output facet will do error reporting in
a non-standard way would not it be confusing? I thought that if I'm
using a type with a "standard" input/output stream then it should behave
in a "standard" way. Why would I want to go into time period error
reporting details? What make it so different that as a user I really
should spent my time reading the docs and why should I break my "normal"
usage patterns for the time period or any other data time object? This
is what I'm missing. What is so special about time periods? :)

If there is something unsatisfactory with the error reporting for the
input/output facets in general. Then I think it should be a separate
thread. Just to make it prominent that this question is not related to
acceptance of my patch =)

>> %H in an output facet
>> ---------------------
>> The hours value is converted into a string. There is a BOOST_ASSERT
>> that checks that the value is no longer than 2 characters. At the
>> same time a zero is perpended if the value is shorter than 2 characters.
>> Note that there is no check for the value of 23 or 24. Just for the
>> length of 2 characters.
> Technically, this check is intended to ensure that the formatted string
> will be parsed back with the %H specifier. That will hold if hours
> string is no longer than 2 characters.
>> %H in an output facet
>> ---------------------
>> A continuous sequence of digits no longer than 2 is read from a
>> stream. If there is less than 2 digits it is an error. Read digits
>> are converted into a number. Actually it means that the current
>> behavior is wrong with regard to the ptime or time period.
> What exactly is wrong?
>> %H in an input facet for a ptime bug
>> ------------------------------------
>> The following code
> [snip]
>> Gives me this output on MS cl:
>> 2009-Jun-17 04:14:00
>> fail is false
>> While it would have failed to parse the input value, in my opinion.
> I believe it's not a bug. The read date is normalized correctly.

If we do normalization then why don't we allow for 3, 4 or 5 digits in
the hours field? Certainly there could be more than one opinion on this
subject but I think that the ptime input facet should fail if it reads
value of 27 in the hours field. This is something that can not be
generated by a ptime output facet and is very suspicious. What will you
think if your digital clock will show you that it is 27:16? I doubt
that you will think that it is 03:16 of the next day :)

In other words I think that range [0, 24] for the hours field is part of
the ptime syntax. And input facet should fail to parse a string that is
syntactically incorrect - as the one used in my example.

I have not read the "ISO 8601", but a shallow examination seems to show
that the standard does not allow anything except [0, 24] for the field
and the value of 24 is allowed only under special circumstances. As
there are references to this standard in the documentation it adds
confusion if the library behaves differently from what is written in the

Boost list run by bdawes at, gregod at, cpdaniel at, john at