Hi Vicente, Howard and all, [First a status on my failed attempts:] I am back with a personally disappointing news. The date<rep> turned out to have a flawed design that I should have seen from the outset. To be concrete, I should at least show a subset of its prototype: template<class rep> class date { typedef date_rep_traits<rep> traits; rep date_mem; public: typedef rep::year year; typedef rep::month month; typedef rep::day day; template<class rep2> date operator-(date<rep2>); template<class rep2> date operator<(date<rep2>); //and other similar operations }; The idea being that same operations can be performed on two date objects with different reps. But I realized this was a bad idea both in theory and practice. I decided on this endeavor making false parallels with the rest of the chrono library. But there, the rep is a type that behaves like an integer. Thus, rep is pretty well defined. But in my library, rep is a full blown class. A user of date who needs a custom rep, needs to define all its functions like year() etc, at which point he is halfway through the whole date class itself. What he is doing is supplying the implementation of date class himself. Thus, I took the wrong conclusion from the benchmark report you forwarded [1]. Since ymd representation shines in certain cases, I sought to appease the class that would find ymd representation better. But in applications that require only input and output of field values year, month and day, a simple structure would serve the purpose too: struct simple_date { int year, month, date; }; And so there is no point to rep now. Moreover, since our library is general purpose, there is no point in providing a calendar other than the dominant one i.e. p. gregorian. The report [1] again proves that it is better in practice too. Thus, there is no point in making date as a template. I am sorry to say it was needless direction but a re-reading of [1] compels me to choose the recommendation: to implement the date class as a cached-serial implementation. So, I am happy to say that my proposal has actually gotten narrower than 2 days back. I will try to focus on this implementation only and make it as fast as possible. I need expert opinion as to whether my decision sounds sensible or not. 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". Is it true then that Boost.chrono library originated after the idea came from the paper? 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? 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? 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? 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. 5) Am I posting the questions in the right place, or should I take them to a more appropriate forum? Thanks, Anurag Kalia. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3344.pdf -- View this message in context: http://boost.2283326.n4.nabble.com/gsoc-2013-draft-proposal-for-chrono-date-... Sent from the Boost - Dev mailing list archive at Nabble.com.