From: Vicente BOTET <vicente.botet@wanadoo.fr>
De : "Artyom"
Why have you preferred to redo Boost.DateTime?
If the DateTime library is redone, shouldn't it be released as a separated
one, DateTime2?
No, because they have very different purposes.
There is almost no locale dependent libraries in Boost while boost::locale::date_time is strictly locale dependent.
It provides same interface for different calendars and they may be changed in
the runtime.
I think that internationalization is a traversal concern that could be applied to a lot of libraries. For example, it could be applied to Boost.Ratio, Boost.Chrono, Boost.Units. This doesn't means that all these libraries must be inside Boost.Locale/I18N. So yes, I'm sure that it will be better you provide a separate proposal for, let me say, Boost.Calendar or Boost.Dates that will use whatever is needed to make dates, calendars internationalizable.
The real problem that if you need internationalizable calendar you will need ICU... Because it is damn hard to implement a dozen of different calendars: Hebrew, Islamic, Japanese, Chinese and so on and handle for all of them time-zone. Just for the record the time zone support in Boost.DateTime is broken. See: http://cppcms.sourceforge.net/boost_locale/html/dates_times_timezones.html#d... So how can I say... It would not be simple. Boost.Locale creates an abstract calendar for calendar operations and separate formatting facilities (including different calendars) via time point represented as POSIX time. Everything may be localized but the question how hard should you work.
Why your datatime class output by default as a number? Why there is no a default format?
Because date_time is approximately a number that represents a time point in UTC (POSIX time) - seconds since Jan 1, 1970 GMT without leap seconds.
boost::time_point<> is also an opaque number. This doesn't mean that it is anumber. This doesn't explain why a default other than a raw number is not better. I would expect that it outputs as a date + a day time.
Actually, in second thought I can change the default. It shouldn't be a big problem. Other reviewer requested this as well. I need only ensure that formatting flags would change it. Also small note, that may be little bit confusing: date_time hebrew_calendar_date = ...; output_with_gregorian_locale << hebrew_calendar_date Would display Gregorian date as the calendar is rendered in the context of the target stream's locale
Basically there is a separation of roles:
- date_time calculates times - iostream formats numbers - numeric representation connects between them.
I don't see an explanation to choose as default the hidden representation.
Numeric is just most universal one. But I think I'll change the default. (note above)
By the way, i would be interested in adapting Boost.Chrono to use Boost.Locale/I18N. Maybe a future Boost.Calendar library would use Boost.Chrono.
Actually it is sounds interesting. However Boost.Chrono has its own goals while boost.locale has different so we should think how to do it right in future. Best, Artyom