Le 27/04/13 10:55, Anurag Kalia a écrit :

...

Where is it? I am very sorry that I didn't upload the proposal itself! It just feels foolish. I have attached the original proposal here.

Hi Kalia, I will start with some concrete points on your proposal and finish with some points you have not covered. * Do we need a typedef for days_point? The usual way in chrono is to define clock and durations typedefs but not time_point typedefs. typedef std::chrono::time_point day_point; * Why do you want date to inherit from this day_point? Do you want to make implicit conversions from date to minutes or seconds? I would instead define an explicit getter function otherwise you would inherit form all the time_point<> operations which is not what we want. * I don't know if your day_clock is a digression or you want to define it. In you define it it seems natural that your day_point would be instead typedef days_clock::time_point day_point; But then you would not have the implicit conversion to a system_clock::time_point. * What could be the use of the typedef month31, month30, month28, month29, year_normal and year_leap and the associated types jan, feb_normal, feb_leap, ...? * About the change_day, change_month and change_year. First the name change_ doesn't mean add. What is wrong with the days/month and year arithmetic that allows to just write d + days(1) + month(1) + years(1) instead of d.change_day(1); d.change_month(1); d.change_year(1); * chrono::duration for months/years I would use instead average_months and average_years * H.H proposal as well as my adaptation use a internal duration for months and years with closed arithmetic. If you use your typedef duration> months; typedef duration> years; then following date next_month = today + months(1); would not represent the next month but an approximation of the next month, that is today + the average number of hours of a month :( * I/O I don't like to associate the format with an instance of date. This spend memory and a user would expect the same format independently of how this instance has been constructed. Would your provide input of a date from an input stream on your library? * There is a typo in date d1 = date(2) / month(4) / year(2011); * Please don't use CamelCase for the Month and WeakDays * I disagree with your point of view respect the use of _1st, _2nd, ... forbidding its usage for nth day of the month or the nth weekday of the month doesn't prevent you building invalid dates. Note that you are able to build an invalid date even if you don't use these nth symbols, e.g. day(31)/april/2013 If you want symmetry you could use use nth(1) and nth(-1) . * Could you add to your proposal the description of the different representations you want to take in account? Now I will continue with the things that are not in the proposal: * one important thing is how and when dates are validated? Can the user construct invalid dates? * If you propose to have several date classes with different representation you need to clarify how the conversions of the different representations is done? * Would your proposal improve the performances? * What your interface adds to the one proposed by H.Hinnant? Why this is an improvement for your? I understand that you want to design your own library, I did the same, but getting a coherent design would take you some time. I suggest you to start with the H. Hinnant proposal as a reference and state what you want to added, changed or removes. State clearly why do you want these changes, what would be improved/solved. Don't forget to inspect the threads/discussion related to the H.Hinnant proposal, and the paper N3344 Toward a Standard C++ 'Date' Class http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3344.pdf HTH, Vicente

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.

On Apr 30, 2013, at 3:14 PM, Anurag Kalia wrote:

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.

Time zones are important. UTC and local are critical. Being able to manipulate dates in additional time zones, other than UTC, is very helpful. Consider a multinational corporation consolidating information from multiple sites. Where the program runs dictates the local time zone, which might be used for logging timestamps. The data's source dictates the time zone of time stamps in the data. Neither time zone need be UTC. One could switch the local time zone to that of the data, convert each date/time to UTC, switch local back to its original value, and then use UTC only with the data, but during the switch, the log time stamps would be wrong. One of the flaws in Boost.Datetime is the time zone support only accounts for two changes per year: DST on and off. However, other changes can be legislated any given year. Another deficiency you might consider addressing is multi-year time zone support. That is, based upon the date/time being represented, which time zone rules apply? Know that you cannot please all interested parties with a single date/time class. Special cases often require special purpose classes and need not, necessarily, be standardized. Look to other programming languages and libraries for inspiration and scope. ___ Rob (Sent from my portable computation engine)

On May 1, 2013, at 6:50 AM, "Vicente J. Botet Escriba" wrote:

Le 01/05/13 11:02, Rob Stewart a écrit :

...

...

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. Time zones are important. UTC and local are critical. Being able to manipulate dates in additional time zones, other than UTC, is very helpful. Consider a multinational corporation consolidating information from multiple sites. Where the program runs dictates the local time zone, which might be used for logging timestamps. The data's source dictates the time zone of time stamps in the data. Neither time zone need be UTC. One could switch the local time zone to that of the data, convert each date/time to UTC, switch local back to its original value, and then use UTC only with the data, but during the switch, the log time stamps would be wrong.

Rob, do you think timezones are must have feature for a Date library?

Yes

...

One of the flaws in Boost.Datetime is the time zone support only accounts for two changes per year: DST on and off. However, other changes can be legislated any given year. Another deficiency you might consider addressing is multi-year time zone support. That is, based upon the date/time being represented, which time zone rules apply?

Know that you cannot please all interested parties with a single date/time class. Special cases often require special purpose classes and need not, necessarily, be standardized. Look to other programming languages and libraries for inspiration and scope. Note that my intention here is to explore the domain, not making a C++ standard proposal.

I see.

I suspect that the proposal to the standard would contain only one date class. Having a library that shows that we could have several date classes that works well together could make the the committee switch from a concrete date class specification to a Date concept and one possible implementation.

I'm not certain they would standardize just one class, but I like the direction you're pursuing in either case. ___ Rob (Sent from my portable computation engine)