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:29:32

On 2013-05-11 15:13, Vicente J. Botet Escriba wrote:
> Le 11/05/13 11:54, Roland Bock a écrit :
>> On 2013-05-08 18:08, Vicente J. Botet Escriba wrote:
>>> Hi,
>>>
>>> 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);
>> Hi,
>>
>> 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++? 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 :-)
> We have suggested a more neutral factory
>
> auto dt = make_date(year(2013), may, 11);

Yes, I like that much better. The main point I was trying to make is
that using operators to mimic the way some people are used to writing a
date is not necessarily the best idea.

May/11/2013
11.Mai 2013
11.5.13
2013-05-11
...

There are just so many ways. Allowing such formats in code just adds to
confusion, IMHO.

>> Another question I have about this is: Is is really a good idea to use
>> operator/()? It does prevent you from calculating ratios between
>> periods, e.g.
>>
>> int ratio = year(3)/month(4);  // ratio = 9
>>
>> I'd therefore prefer another operator, e.g.  operator <<
>>
> year,month and day are unit specifiers not periods (years, months, days).
> The ratio is obtained using
>
> int ratio = years(3)/months(4);  // ratio = 9

Hmm, seems like I missed a lot of the discussion. I'll need to read up
on that, but I admit it seems weird to me to have to distinguish between
years as a period and year as a "unit". I mean, for instance 'm' is a
unit, 10m is a distance (not 10ms), ft is another unit for distances,
and there is no harm in dividing 10m by 5ft.

Calendar units are a bit weirder than the MKS system, but still...

Anyway, I'll read more :-)

Regards,

Roland
>
>
>> But to be completely honest: I don't see the benefit of constructing
>> dates this way. Why not simply use a constructor?
>>
>> date(year, month, day);
>>
>> With C++11 you could then write:
>>
>> date ISO_week_start = mon <= { y, jan, day(4) };
> I guess this depends on the type of {y, jan, day(4)} and the expected
> type of the rhs of the operator<= ?
> ???  operator <=(month, ???)
>
> Note that we are talking of several dates types.
>
> { y, jan, day(4) } would be accepted where a ymd_date is expected.
>
> The operator <= is defined on serial_date as the algorithm is
> efficient only with this representation.
>
>> That's the way I'd prefer :-)
>>
> In order to support
>
> ymd_date ISO_week_start = mon <= { y, jan, day(4) };
>
>
> we need to define operator <= for ymd_date or as a template,
>
> template <typename Date>
> Date operator <=(month,Date);
>
> but the implementation would do a conversion from Date to serial_date
> and return the conversion of the calculated serial_date to a Date.
>
> Best,
> Vicente
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost