Re: [boost] [chrono/date] conversion between concrete dates

On 2013-05-11 15:22, Rob Stewart wrote:

On May 11, 2013, at 5:54 AM, Roland Bock wrote:

...

On 2013-05-08 18:08, Vicente J. Botet Escriba wrote:

...

as the conversion between concrete dates could be expensive I guess that these conversion must be explicit.

But this has some consequences when used the implicit conversion was hidden a not efficient implementation, e.g.

date ISO_week_start = mon <= jan/day(4)/y;

jan/day(4)/y should be ymd_date as is the efficient representation.

The date generator was declared as

date operator<=(weekday wd, date x);

Do you really want to allow/document/support/advocate the American date format in C++? Why not restrict the format to something close to ISO date format for ISO C++? If the types are unambiguous, such as with day, month, and year types, then any order can be supported. Those comfortable with a non-ISO order can do what they prefer with type safety. Sure, you could, and if the library were a direct user interface, I'd say: "Nice baby steps, but not nearly there yet" ;-)

But I don't see a benefit for a library to support different date formats in code. And in terms of code readability, I think it is not a good idea to allow too many options, even though they are typesafe. The next programmer to read your code might be more comfortable with a different order and might not think like a compiler (and be confused).

...

That way you could introduce a new type, say ym_type and

ym_type operator/(year y, month m); date operator/(ym_type ym, day d);

Neither explicit nor implicit conversion necessary :-) You misunderstood the conversion context. There are several formats in contemplation: serial, days since an epoch; ymd; day of year; week of year; etc. conversions among them are sometimes costly, so the notion is to make them explicit.

True. As I wrote in reply to Vicente, I obviously missed major parts of the discussion so far, so I am not going to argue about the conversion before I read more about that :-)

...

I'd therefore prefer another operator, e.g. operator << -1

That operator is for I/O, even if unsupported. (Someone might want to add I/O, even if not standardized.) Agreed.