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

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