RE: [boost] Date/Time to string conversions

From: Yitzhak Sapir (yitzhaks_at_[hidden])
Date: 2002-12-10 10:23:27

On Sun, 8 Dec 2002, Jeff Garland wrote:

> Yitzhak Sapir wrote:
> > The date/time library provides several implementations of date/time string conversion.
> > Unfortunately, none of these include formatted date/time conversions.  In trying to
> > duplicate the functionality of VarFormat for dates, I can do so (relatively) easily
>
> What is VarFormat.  I assume you mean something like "%Y %B %d"?

Sort of, but Windows specific.

> Yes this is true.  Of course it can't provide internationalized strings
> or wide strings.
>
> > But I can't construct a greg_month (which is undocumented in the main
> > documentation, btw), from a string.
>
> Yes, you have to convert it to a month number first.  I assume
> you have looked at the code in boost/date_time/date_parsing.hpp?

This is less of an issue for me now, since I don't need to do this :-)
However, the reason I didn't look at that file is because it wasn't
mentioned in the documentation.  So I have to use the documentation as
a reference while reading the source code, rather than the other way
around.  As an example, while I was looking at the documentation, I
noticed that date_period does not have length() documented.  The entire
parsing/formatting functionality is not documented and not used in the
documentation (ie, when values are printed, they're printed via
to_string() functions).  Even things that are documented (like
first_kday_after), don't give some information that I feel I need to see
specified (what is the first_kday_after(Jan-1-2002, Tuesday)?).

> > I think greg_month/greg_day/greg_year should all export
> > from_short_string, from_long_string, from_char, etc.
>
> In general, based on review comments, the library has moved to
> using iostreams with facets for doing I/O since this takes into
> account the issues of localization and wide characters.  There
> was controversy about whether string conversion should even
> be part of the library with some suggesting it should be removed
> in favor of streaming -- which of course can provide conversions
> to strings.  I decided to leave it there because some older but
> heavily used compilers (gcc 2.95.x, MSVC 6.5) have issues with
> support for localized I/O which the stream-based solution uses.

What problems are there with MSVC 6.5?  I'm now all ready to go with
streaming, but the MSVC6.5 warning disturbs me a little.  How about
MSVC6.5 + STLPort?

Dates use a locale facet quite well.  Time does not.  Using the expression
"stream << time", does not get you an output depending on the stream's
locale's definition for hour separator, minute separator.  Some base work
is done in iso_format.hpp, but I see no use anywhere in the library
(using a file search) of iso_format.hpp's fractional_time_sep_char() for
example.  I see no way to set whether .000 is outputed when the fractional
part of the seconds is 0.  Maybe I'm missing something here.

Other comments: I  see no way to retrieve easily the number of
milliseconds from a duration.  I can only extract the "fractional
seconds" which depends on the platform I compile on, as far as I can
tell, and does not seem to me to lend itself to portability.  There is no
millisecond_clock or anything more precise beyond second_clock(), while
I suppose most platforms would be able to provide such a thing (although
in system specific ways), and probably even higher resolutions.  While I
can write such a thing, what the library provides seems to constrain me to
what C provides only.  On that note, I suppose something similar can be
said for writing a facet.  It seems that there is no ready-made facet to
use for this, and the user has to provide his own, giving arrays of all
the day names etc.

week_number does not seem to take into account localization variations,
that seem to exist, such as whether Sunday or Monday is the first day of
the week.  I'd also like to have the ability to specify the minimum number
of days in the week.

I think it's a good library, but it's lacking many things that would make
it easier to use, or at least, I didn't find many things after looking
through the sources for several hours trying to understand it.  Most of
these things are things I need, so I feel I'd need to do them anyway, if
they are not there already.