Re: [boost] [chrono/date] Unit specifiers arithmetic

Subject: Re: [boost] [chrono/date] Unit specifiers arithmetic
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2013-05-06 09:34:08

On May 6, 2013, at 6:31 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:

> Hi,
> 
> Moving from checked dates to unchecked ones by default and forcing to user the Unit specifiers year/month/day in any date constructor (even the unchecked ones) has some ugly consequences. Note that I was able to build an unchecked date as
> 
> date d(2013,5,6, no_check);
> 
> Given
> 
>  year y;
> month m;
>  day d;
> 
> the following will not compile now as the constructors expects a year but y+1 is an int.
> 
>  date d(y+1, m, d);
> 
> The user needs to type
> 
>  date d(year(y+1), m, d);
> 
> Is this what we want to provide to the user or should we add basic arithmetic on these unit specifiers?

This is an example of where flexible ordering and implicit last unit starts to shine.  Examples from my 2011 paper:

        start = mon <= jan4/(d.year()-1);

        date next_start = mon <= jan4/(start.year()+1);

Or translated to your example and syntax:

    date d(d, m, y+1);  // works because last unit can be int

If we start adding arithmetic to the unit specifier day, it becomes indistinguishable from a duration.  Now it is possible that we could use durations as unit specifiers.  But that seems messy to me, especially for months and days.  However it would align us more closely with struct tm, which specifies many (but not all) of its fields in terms of durations:
     
    int tm_mday; // day of the month — [1, 31] -- a day specifier,
                 //     but could be reinterpreted as days since last day of previous month
    int tm_mon;  // months since January — [0, 11] -- a months duration

Howard