RE: [boost] Date/Time formal review

From: Paul A. Bristow (boost_at_[hidden])
Date: 2002-04-29 12:53:09

An intellient parser would be extremely valuable and popular IMHO.

It should NOT be picky about separators and the month in letters
should be locale sensitive, and the dmy order should also be
locale sensitive.

For human input this is really important
(whereas for reading computer generated input a strict parser is also
vital).

Paul

> -----Original Message-----
> From: boost-admin_at_[hidden] [mailto:boost-admin_at_[hidden]]On
> Behalf Of William E. Kempf
> Sent: Friday, April 26, 2002 2:37 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Date/Time formal review
>
>
> ----- Original Message -----
> From: "Kostya Altukhov" <kostya_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Friday, April 26, 2002 6:00 AM
> Subject: Re: [boost] Date/Time formal review
>
>
> > William E. Kempf wrote:
> >
> > >That said... I'm not sure that parsing (reading) of dates
> should actually
> > >strictly conform to any format string.  As long as the strings
> are never
> > >entered by a human this works, but if you need to allow for human input
> (and
> > >can't constrain the input with something like a GUI formatted input
> widget)
> > >then the exact parsing becomes nearly useless.
> > >
> > I think that a strict parser based on format string will be
> useful even if
> > more intelligent option is also provided. After all, input
> validation and
> > date parsing are different tasks. In many cases at the time of parsing
> > we are sure about the format of the input string, and in these cases I
> > would prefer to rely on strict format parser rather than to trust some
> > guessing algorithm.
>
> Sorry, I did not mean to imply it was a one or the other choice.  What I
> meant to imply was that a choice of only strict parsing is not acceptable.
> A choice of only a more flexible parsing would at least cover more cases
> (unless the point of parsing is to verify strict adherance then
> the flexible
> parsing will work, although possibly less efficiently), but it's
> not what I
> was suggesting.
>
> Bill Kempf
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost