Boost logo

Boost :

From: Martin (adrianm_at_[hidden])
Date: 2004-09-28 04:23:40


> > 1. Why doesn't date_time use the standard time facet
> > (time_put.do_put etc) if the special greg_date_facet isn't available?
>
> Couple reasons. We have looked at using the current facets, and sadly, in
our
> testing we found most of the current facet implementations don't work
> correctly

That is what I suspected. Thanks for the explanation.

> -- so even if we did use them it wouldn't work. Second, the standard
> facet doesn't cover all values that date_time offers such as infinities,
> not-a-date-time, etc.

I was only suggesting to use the standard facet as a fallback solution since
that way you don't have to mess with local formatting in user messages.

Currently I convert the date/time to "struct tm" and use strftime.

> Yes we realize this is a pain. The plan is to provide manipulators to
control
> these aspects so you don't have to mess with the facet to control seperators
> and ordering.

Maybe it is just me but I prefer the facet way since then I can apply it
either globally or to a specific stream. With manipulators there is no way to
control the date format used in e.g. the program options library.

Why not create a facet which uses the standard strftime formatters and also
lets you use custom names for days & months. If %a,%b etc is specified just
check if custom names are available, otherwise let the standard time_put::put
() (or strftime) handle it.
%c,%x & %X should always be handled by time_put.

With this facet you can do:
xmlstream.imbue(locale(locale::classic(), new date_time_facet("%Y-%m-%dT%H:%M:%
S")));

Parsing date input is always tricky but isn't that a reason to have it as a
library function.

Different facets or constructor overloads is probably needed to handle
different cases like only date, only time & intervals.

I can help with implementation if you like.


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