Boost logo

Boost :

From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2001-03-22 10:42:18


> --- In boost_at_y..., "George A. Heintzelman" <georgeh_at_a...> wrote:
> > <sniped interesting things about Date classes>
> <rant>
> Please, whoever thinks about writing a Date in string format
> there is A STANDARD format, ISO 8601, for doing this.
> I would not end up coding a new input format for each and every new
> data file :-(((
> It should really be the default (I'm tempted to say the only!) way
> of writing your dates in string format.
> Stop the madness, refuse the american (is it really american? )
> middle-endian format :-)

Well, we do it that way most of the time, yes. Sorry. Dunno who else
does it our way.

> I know someone who missed a flight because the date was written
> mm/dd/yy !
> How are we suppose to sort thoses !

By having the date class do the parsing and then using its comparison
operator!

> </rant>
> Sorry for the rant, but I HATE parsing the n+1th date format someone
> thought up as a way to express his creativity.

I do too. My point is that with careful consideration of the IO
manipulators, we should be able to shove all the parsing work to the
date class, and let people tell the class what format it will be in:

For example:
using boost::date_format;
is >> date_format("mm/dd/yyyy") >> date; // "04/22/2023";
is >> date_format("dow, dd mon, yyyy") >> date; // "TUE, 22 APR, 2023";

I'd love to have a universally-used standard representation.
Unfortunately, it doesn't exist (ISO notwithstanding), and forcibly
standardizing all the currently-existing protocols that transmit dates
is an impossible task. We can set the default representation to the ISO
one, but if people can't easily use the class to deal with whatever
representation is used by the outside service that they have, it will
be almost useless, and just one more contributor to the mish-mash that
is already out there.

George Heintzelman
georgeh_at_[hidden]


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