Re: [boost] [date_time] i/o formatting

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2006-02-28 07:28:08

> Don't really see why you need manipulators. If you want to use the US date 
> format do setlocale("US"), if you want German dates do setlocale("DE") etc. 
> That is how you do it if you want numbers formatted and don't see why dates 
> are any different.

I don't want to use the "US", "German" or any other specific regional 
settings - I want to use *my* settings.

> If you are writing an application that need to parse/print dates in a more 
> generic matter use a facet just as you do to handle different decimal 
> separators.

But this is just most inconvenient...

>>I think of specifying the format string as similar to specifying the 
>>printing precision of a float, or specifying that an integer should be 
>>printed as hex. These are provided as manipulators without the 
>>complexity of facets (which most users, including me, know very little 
>>about).
> 
> I don't agree with that comparison. Date formatting is more like the number 
> formatting (decimal separator, grouping etc) which is part of the locale for 
> numbers.

You have a point with the decimal separator issue (decimal separator as 
an example).

After thinking about it some more, perhaps what I'm complaining about is 
something that is general in the locale/facet system. Maybe what's 
really bothering me is that once a certain setting is considered as 
"locale related", such as the decimal separator, it can only be 
configured using the locale/facet over-complicated way. But sometimes I 
don't want to use the "US", "German" or any other local setting for a 
decimal separator - I want to use *my* decimal separator. I souldn'd be 
forced to use a locale in such cases, IMO. IOW, I wish *all* settings 
would be configurable using manipulators (or an equivalent convenient 
way), and yes, that includes a decimal separator manipulator...

The date_time I/O just brought all this to the surface, because setting 
a date/time format string is much more common than setting a decimal 
separator, but in principal it's the same thing...