Boost logo

Boost :

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...

Boost list run by bdawes at, gregod at, cpdaniel at, john at