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-17 07:30:44

On Wednesday 17 June 2009 14:40:20 Ilya Bobir wrote:
> Andrey Semashev wrote:
> > 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? :)

I'm not sure what you're advocating for. What error reporting strategy do you 
call "standard"? In the discussed matter an assert is used - is it "standard" 
or not, in your terms?

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

I think, I've said it somewhere. %H is bound exactly to 2 digits to support 
format specifiers without delimiters, such as %H%M%S. It is irrelevant to 24-
hour limit.

> 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 :)

I would think so, actually. I admit that 27:16 is not a usual time 
representation, but nevertheless I think that normalization may be useful and 
is a valid behavior.

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

It is syntactically correct.

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

In any case, I think, we both in no position to settle this argument. I'd 
prefer to see what the maintainer thinks of it.