Re: [boost] [gsoc 13] Questions regarding Boost::chrono and as well as Boost::chrono/date

Subject: Re: [boost] [gsoc 13] Questions regarding Boost::chrono and as well as Boost::chrono/date
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-30 17:30:37

Le 30/04/13 21:14, Anurag Kalia a écrit :
> Hi Vicente, Howard and all,
>
>
> I have a few questions in order now after reading the discussions of the
> google group you sent (lively, they were!) and other similar endeavours:
>
> 1) I saw involvement of Vicente and Howard in the current Boost.chrono
> library. What inspired the library when Boost.date_time also offers a
> date_time class? The motivation section in boost docs mention an open-std
> paper "N2661 - A Foundation To Sleep On".
This paper is not related to date, but time points and durations, the 
origin of std::chrono.
>
> Is it true then that Boost.chrono library originated after the idea came
> from the paper?
Most of the design if not all is due to Howard. Beman did the major part 
of the porting to Boost and making it portable to several platforms, I 
just made it ready for review to Boost.

> If so, why is it that C++11 supports only conversion to and
> from <ctime> library functions for user-readable output? Boost.chrono
> duration and time_point classes provide their own output operators after
> all. IMO, it reduces std::chrono to just a timestamping library, having no
> features to add time of its own, but why are the actual reasons for
> differences among the Boost.chrono and std::chrono library?
The Boost.Chrono I/O while non in std::chrono comes also from Howard. I 
have ported it to Boost and implemented a variation in Boost.Chrono V2.
Note that there are not too much classes in the C++ standard with I/O.

Making a proposal to the C++ standard committee takes time. It is better 
to propose it once the interface has been used, is good enough and don't 
contains conflicting parts. The feedback of the committee for the H.H 
proposal was good except for the performance part, hence the paper in[1].
> 2) Why are we creating a date class at all, when we have a
> boost::gregorian::date class already in date_time? We are duplicating
> facilities all along. What the differences would be, if any, among the two?
> I am totally postulating here, but is it the case that Boost.chrono/date
> proposal also came through an intention to implement a C++ date class from
> the ground up, without looking at related stuff in Boost that was already
> done?
Well chrono::date is an attempts to provide something simpler than 
Boost.DateTime as a proposal for the standard. It has a simpler 
interface and avoid some of the conflicting issues a DateTime library 
could have. it is an step forward.
> 3) Reason for these two questions: strftime has been majorly upgraded in
> C++11 and it can easily support output of date only. Why would a C++
> committee approve redundancy in such functions, though agreed that a date
> class is really different from a date_time class? How much support though,
> should be built in a date class anyway for such functions which don't seem
> to be legacy by any means?

strftime is a C function. The C++ standard committee could accept only concrete proposals. Boost.DateTime as such has not been proposed to the C++ standard committee.

>
> 4) I never took timezone into consideration for output. It needs to be
> incorporated because it is too big an omission. I discovered it only two
> hours ago so I need time to incorporate it. Are timezones other than utc and
> local important? Unix, Boost.date_time and Boost.chrono seem to support
> these two timezones only. What are the motivations to restrict timezones to
> these two instances? They seem to be the minimum possible set required to
> display time. I am still reading up on this stuff, so probably a little more
> reading will answer this part.
Which timezones would you like to add?
>
> 5) Am I posting the questions in the right place, or should I take them to a
> more appropriate forum?
If you want some complementary feedback you could post to 
std-proposals_at_isocpp.org. This is an open forum as it is 
std-discussion_at_isocpp.org.

Best,
Vicente

[1]http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3344.pdf