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

Subject: Re: [boost] [chrono/date] conversion between concrete dates
From: Roland Bock (rbock_at_[hidden])
Date: 2013-05-11 10:41:59

On 2013-05-11 15:22, Rob Stewart wrote:
> On May 11, 2013, at 5:54 AM, Roland Bock <rbock_at_[hidden]> 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.