* *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. Agreed. I will use contextual dates from now on, until some one find a better name. 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. In the Howard implementation the last attribute is lost after day arithmetic. Is this what you meant? What I want is a contextual date that has always a context independently of the year/month or day arithmetic. And of course when a contextual date is converted to a (non-contextual)date the context is lost. As you rightly say, this should be made explicit. Well up to us to decide. For the time been I admit the drawback of implicit conversion. I can change after more experimentation. have no other suggestion than saying that we adapt the make_date() syntax for this use-case scenario too?
Le 05/05/13 00:05, Anurag Kalia a écrit : the make_date and the operator/ factories should work for contextual and non contextual dates.
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); }
I have never thought about doing it this using the year_month. I like it. There is a single point that I intended to raise. Would a non-contextual date accept a contextual parameter as day of the month, or should we use the factory std::cout << make_date(ym, last); But how a contextual date should output? Humm I really don't know yet. So to be sure we will need an explicit conversion std::cout << date(make_date(ym, last)); This is not very nice. I think it is useful to build a non contextual date giving a context that is lost after construction. So date dt(y, m, last); date dt(y,m, monday[_3rd]); should be correct but not contextual.
Suddenly I understand Howard's desire to include it. What 'it' stands here? 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? I have a class month_day, but I didn't implemented month/year arithmetic on it. I guess this could be useful.
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?
See Howard proposal, this is explained there. The reason is that day arithmetic on Howard date class loss its meta-data context. Best, Vicente