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.