RE: [boost] Date/Time to string conversions

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-12-08 08:23:50

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"?

> only in one way (from date to string), since each date component provides the 
> necessary to string conversion functions.  

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?

The primary reason for this is the diversity of potential 
possible conversions from a string.  In the case of months 
you might need to handle:
  'Feb'
  '02'
  'February'
  'Februar'  //german
  'Febrero'  //spanish
  ...

And then there are wide strings.  The same problem for greg_weekday.

> The short/long strings are declared privately and so I must duplicate 
> this functionality (and constant strings) if I want to implement 
> formatted input.  While I could duplicate it (cut/paste), I don't 
> think I should need to. 

I agree you shouldn't need to cut and paste.  But, check it again, 
they are public.  I think the problem might be that greg_day and 
greg_year don't have to_***_string methods at all.

> 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. 

So my preference would be to implement any varFormat capability 
in terms of streams and not strings at this point.  Anyway, if 
you are serious about working on this and can contribute to the
library I would be happy to work with you on it.  

Jeff