Re: [boost] [locale] Review. Internationalization library?

Subject: Re: [boost] [locale] Review. Internationalization library?
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-04-16 16:44:35

> From: Vicente BOTET <vicente.botet_at_[hidden]>
> > 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#dates_times_timezones_qna

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