* *Do we need to make the separation between absolute and relative dates?* IMO, yes. While relative dates are powerful they incur on unwanted overhead when absolute dates are needed. I can guess what you mean by relative and absolute dates, but I'd rather not. Can you briefly describe what these types of dates are?
The date class of your proposal is what I call a relative date, as it contains meta-data as last day of the month, 2nd sunday of month, ... Arithmetic on relative dates is often quite powerful. We could call them contextual dates or a better name if you find it. What I call an absolute date is a date that has no meta-data, it defines exactly a date without a context.
28/feb/2013 is an absolute date while last/feb/2013 is a relative/contextual date.
Taking one of examples in your original proposal
// Print Feb. 28 for each year in the decade for (date d = feb/day(28)/2010, e = feb/day(28)/2020; d != e; d += years(1)) std::cout << d << '\n';
// Print the last day in Feb. for each year in the decade for (*rel_**date* d = feb/*last*/2010,*date* e = feb/*last*/2020; d != e; d += years(1)) std::cout << d << '\n';
rel_date implicitly converts to date of course, so that the comparison works as expected, the opposite not been true.
So the following is valid
date dt = feb/last/2020;
It is also true that this implicit conversion could result in surprising behavior (as usual)
// Print Feb. 28 and notthe last day in Feb. for each year in the decade for (***date* d = feb/*last*/2010, e = feb/*last*/2020; d != e; d += years(1)) std::cout << d << '\n';
Maybe this implicit conversion should be explicit.
I would suggest we stick to contextual dates. Relative dates are a different concept and that can be handled competently by already existing chrono library. So, as per the contextual dates, this actually depends on how much staying power we give to the word 'last'. I think the 'last' attribute ends when the date is made. As you rightly say, this should be made explicit. have no other suggestion than saying that we adapt the make_date() syntax for this use-case scenario too? And on a tangential note, I eat my old words. In this same thread, I have said that we should make year_month implementation defined. Now, I don't think so. Let me give an example: If we want to enumerate the last dates from {jul, 2013} to {jan, 2014}, current api (names may change; what matters is functionality) allows us to write: for(date d = date(2013, aug, 1), e = date(2014, feb, 1); d <= e; d += month(1) ) { std::cout << d - day(1) << '\n'; } I wrote it like this because this was the cleanest I could manage. The comparison between months of different years is clumsy. We do need a year_month class for it. If there were one, it would look like: for( year_month ym(2013, jul), jan14(2014, jan); ym <= jan14; ym += month(1); ) { std::cout << date(ym, last); } Suddenly I understand Howard's desire to include it. And I agree now. it just makes the whole syntax easier. This leads me to my next question, are there uses for similar class month_day?
In your proposal, day arithmetic didn't satisfied the following
assert((aug/last/2011 - day(1) + day(1)) == aug/last/2011);
How come it does not? The fact that the 'last' attribute gives us an absolute date guarantees it. Am I missing something? Regards, Anurag. -- View this message in context: http://boost.2283326.n4.nabble.com/chrono-date-Performance-goals-and-design-... Sent from the Boost - Dev mailing list archive at Nabble.com.