I'm trying to understand the date_time formatting via iostreams but got problems with a few things. I tried to search the archive but didn't find answers to these questions. 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? 2. Why do I need to specify the names of all months and weekdays in the greg_date_facet just to use a different separator than '-' or another ordering? 3. How do I specify the format of a ptime (date-separator, time-separator and decimal separator)? -------------------------------------------- I also got some compile warnings on VC70 (latest CVS) 1: in the function "from_time_t" on this line return start + seconds(t); boost\date_time\posix_time\conversion.hpp(27) warning C4244: 'argument' : conversion from 'time_t' to 'long', possible loss of data 2: in the function "from_stream_type" ss << ss.narrow(*beg++, 'X'); // 'X' will cause exception to be thrown boost\date_time\date_parsing.hpp(211): warning C4244: 'argument' : conversion from 'wchar_t' to 'char', possible loss of data
On Mon, 27 Sep 2004 13:12:20 +0000 (UTC), Martin wrote
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 -- 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.
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.
3. How do I specify the format of a ptime (date-separator, time- separator and decimal separator)?
I'm afraid that's not settable at the moment -- the enhancement is still on the todo list.
I'm still looking at this. We have a fix for the first one -- unsure on the second one. Jeff
That is what I suspected. Thanks for the explanation.
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.
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.
On Tue, 28 Sep 2004 09:23:40 +0000 (UTC), Martin wrote
Hmm, good point.
Well, I've been resisting this, but I agree this is pretty compelling. My main resistance has been that I suspect the implementation will be pretty difficult and well, I can never remember what those darn %M things mean anyway.
Parsing date input is always tricky but isn't that a reason to have it as a library function.
Yes.
Different facets or constructor overloads is probably needed to handle different cases like only date, only time & intervals.
Given that the input is a string it will probably require different facets.
I can help with implementation if you like.
If you are willing to help, let's explore it. My sense of this is that it is alot of work. But, send me some mail offline and we can get started. Jeff
participants (2)
-
Jeff Garland -
Martin