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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
