[boost] [chrono] i/o to locale or not to locale

Subject: [boost] [chrono] i/o to locale or not to locale
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-11-11 13:13:28

Hi all,

currently Chrono provides a limited localization interface for duration 
and time_point I/O that is not satisfactory. The current implementation 
Boost.Chrono V1.2 (Boost 1.48) is based on the alternative A1 (see 
below) in which the hour,minute,second and the epoch can be localized. 
This could give the impression that chrono i/o is localized, but as 
Aryton as signaled it is not enough.

I'm working on redesigning the chrono i/o in order to make a proposal 
with Howard Hinnant to the C++ committee. Two main alternatives

A1- follow the formatting of recognized international body as ISO.
A2- Add localization of specific units and epoch to the preceding format.

It seems that the localized alternative seems to have less chances to be 
adopted, as no other library in the standard is providing these kind of 
facilities, and locale message facility is not completely satisfying.

Things could change if  we had a concrete proposal for improving the 
standard locale library (in which Aryton seems to be working IUC).

More detail on the two alternatives:

A1- Provide formatted i/o following the ISO 80000 
http://en.wikipedia.org/wiki/ISO/IEC_80000, 
http://en.wikipedia.org/wiki/ISO_31-1,

The format for duration could be

<value> <unit>

With unit been day, hour, minute, second, decisecond, centisecond, ..., 
decasecond, hectosecond, ...

Note that the unit is always in singular form and in English.

Next follows several valid inputs for duration

3 day
9 hour
1 second
0 second
-1 second
3.77 millisecond
34 [1/30]second

time_points could be formatted as

<duration> <since epoch>

where <since epoch> is a string that identifies the starting point of 
the epoch's clock, e.g. since boot, since process startup, ....

The string associated to each clock are fixed and configurable 
specializing the trait clock_string

Next follows several valid inputs for time_point.

123456 second since boot

A1.a

We can also consider ISO 8601. IMO, an acceptable format for durations 
could be a variation of the extended format independently of the date.

<hours>:<minutes>:<seconds>[.fractional_seconds]

Note that <hours> here is not limited to 24, and gives the total number 
of hours.

A1.b

An additional alternative could be to represent a duration as following 
a variant of the period representation: P[n]Y[n]M[n]DT[n]H[n]M[n]S in 
which the year and month are represented by days. E.g.

P[n]DT[n]H[n]M[n]S[n]F

P1234DT12H30M5S555F

A2 - Make durations and time point i/o locale dependent.

Based on the previous alternative, add the possibility to add specific 
locale facets that could format a duration following the pattern

<value> <unit>
<unit> <value>
<hours><:><minutes><:><seconds>[<.>fractional_seconds]

Here <value> and <unit> will be formatted following the specific locale 
and in this case the unit could have specific plural forms.

For example in French the user could specialize the facets so that she 
could get

1 jour
3 jours
9 heures
1 seconde
0 secondes
-1 seconde
3.77 milliseconds
34 [1/30] de seconde

and in Spanish

1 segundo
0 segundo
-1 segundo

Add the possibility to add specific locale facets that could format a 
time_point following the pattern

<duration> <epoch>
<epoch> <duration>

system_clock::time_point is a special case that should be formatted as a 
localized date, relative to the epoch 1900/01/01.

A3 - Add on top of A2 some _byname facets.

The fist alternative is in line with the money standard locale category 
that uses standard symbols, as $ or USD.
It has the drawback that the <value> could be localized while the <unit> 
is not, e.g.

1,234 second

Note the use of ','.

The third alternative is IMO closer to the user expectations, but needs 
a better locale messages/by_name facet.

The second alternative is a pragmatic one that left the possibility to 
build A3 when a satisfying messages/by_name facet is available.

Boost.Chrono 2.0 in the trunk is a prototype of A2, that doesn't 
provides facets by locale name, only a default English implementation. 
That means that for the time been, the user needs to imbue a locale with 
her specific facet to get the expected localization (See french.cpp 
example in the SVN repository)

What the Boost community think about this? Towards which alternative 
should Boost.Chrono move? Should Boost.Chrono wait until a concrete 
standard proposal is accepted?

Thanks in advance,
Vicente