Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk