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

Subject: Re: [boost] [chrono/date] conversion between concrete dates
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-11 11:32:49

Le 11/05/13 16:29, Roland Bock a écrit :
> 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.

We need to choose one of the overloaded operators.
> Allowing such formats in code just adds to
> confusion, IMHO.
Why are you confused. Even if I don't use to use May/11/2013 but 
11/May/2013 I don't see how

   auto dt = may/11/year(2013);

could confuse someone. What could this mean other than the declaration 
of a date.

>
>>> 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".
unit specifiers, such a year, are not units but a way to name an 
instance of a given type. Periods are units
> I mean, for instance 'm' is a
> unit, 10m is a distance (not 10ms),
I guess ms stands for meters ;-) The unit is metres not meter and the 
suffix is m. All end with n -s, as seconds, hours, years, ...
> ft is another unit for distances,
> and there is no harm in dividing 10m by 5ft.
The unit specifiers for meters could be used to mean the e.g. the Km 13 
of a specific route.
>
> Calendar units are a bit weirder than the MKS system, but still...
>
>
Best,
Vicente