Hi, After the discussion on other threads I would like to summarize some of my performances goals while refactoring the H.H chrono/date library, just to see if I was wrong and going on the bad direction: 1. *Be able to build dates without validating them.* 2. *I wanted the library to be as efficient as possible when the user uses constant objects or literals, no need to validate at runtime what has already been validated by the compiler*. 3. *Possibility to reassign a date if the parameters represent a valid date.* 4. *No a single date class is better than the others on all the algorithms*. 5. *No additional meta-data in absolute dates so that you don't pay for the relative dates overhead when using absolute dates.* 6. *The user must be able to get all the date related informations at once.* Do you have other? The way I have managed with these goals is 1. *P*rovide an unchecked date construction interface with a no_check_t parameter and an is_valid() function. 2. *T*he date parts day/month/year need to be validated or constructed with no_check_t. 3. dt.set_if_valid(year, month, day) 4. Define the Date requirements all the dates must satisfy, implement ymd_date, days_date, ... 5. Separate the absolute and the relative Date requirements into two Date concepts AbsoluteDate and RelativeDate. Provide at least a relative_date class based on the ymd representation. 6. Conversion between different concrete date classe. H.H approach respond to these goals in a different way 1. date and its parts provide constructors that are not validated, the validation is provided by factories as operator/. 2. I don't think this can be achieved when the date must be validated. 3. No problem, this could be added to H.H approach (at least for its YMD date). 4. Same approach. H.H proposes two classes chrono::day_point (only unchecked) and YMD date. 5. I'm not sure the date YMD class doesn't include meta data (Howard could you clarify your point here) 6. same approach. I have some questions for followed by my personal answer; * *Do you see some unnecessary goals, in particular, is the goal 2**necessary?* IMO, yes. Not providing an interface that allows compiler optimizations is against the C++ philosophy. The question is as always, what would be the gain? In the best case we could avoid 6 comparisons. * *Does the introduction of no_check to achieve goal 1 and 2 results in a uglier date interface?* IMO, yes, but I don't know how to achieve goal 2 without. * *Should a concrete date class provide just the functionalities it is able to do efficiently?* IMO, yes. This would prevent the user of non efficient services (Note that my current design doesn't follows this) * *Do we need a Date concept that a concrete date must model**?* IMO, yes. SO we need two levels, level one provides the most efficient service, level two provides an homogeneous interface. * *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. Best, Vicente