Re: [boost] [gsoc 2013] draft proposal for chrono::date

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2013-05-04 19:33:33

On May 4, 2013, at 6:15 PM, Anurag Kalia <anurag.kalia_at_[hidden]> wrote:

> Anders Dalvander-3 wrote
>> On 2013-05-04 15:26, Rob Stewart wrote:
>>> On May 4, 2013, at 8:46 AM, "Vicente J. Botet Escriba" &lt;
> 
>> vicente.botet@
> 
>> &gt; wrote:
>>> 
>>>> Le 04/05/13 14:28, Rob Stewart a écrit :
>>>>> On May 3, 2013, at 6:24 PM, Anurag Kalia &lt;
> 
>> anurag.kalia@
> 
>> &gt; wrote:
>>>>>> At which point I wonder, why can't we be symmetrical and allow a
>>>>>> function like:
>>>>>> 
>>>>>> make_date(2013, 2, 27);
>>>>> You could have these, instead, for more consistency:
>>>>> 
>>>>> make_date(2013, 45);
>>>>> make_date(2013, w7, fri);
>>>> The later overload is Ok. The following is ambiguous
>>>> 
>>>> make_date(2013, 45);
>>>> 
>>>> and need
>>>> 
>>>> make_date(year(2013), 45);
>>> Right
>>> 
>>>> BTW, do you prefer w7 or w_7? Or a literal 7_w instead of a constant
>>>> object?
>>> I'd prefer at least "wk" if not "week" in the name. I don't think an
>>> underscore is nice there, and I don't like the literal ordering.
>>> Therefore, I'd like to see week7 or wk7.
>>> 
>> Weeks? According to what way of counting weeks? Monday-weeks (Europe, 
>> ISO 8601), Saturday-weeks (Middle East), or Sunday-weeks (Canada, US, 
>> Mexico)?
>> 
>> If boost should adhere to ISO 8601, which I think it should, why not go 
>> all in and mandate ordering of YMD as well?
>> 
>> Regards,
>> Anders Dalvander
> 
> My opinions:
> 
> 1) ISO week date says week as W07. So my suggestion was to not deviate too
> much from it: w7, W7 and W07 are all acceptable to me. w7 is the easiest to
> write among them so the first choice of mine.
> 
> That is, if we mandate use of enums at all. Otherwise, sticking to week(n)
> is the cleanest option.

Or is iso_year_week another field type, which could be converted to and from the serial type?

> 
> 2) We should stick to ISO 8601 week standard, i.e. Monday weeks. They are
> not commonplace enough to warrant multiple notations.
> 
> OTOH, the different day formats are actually followed in different
> countries, according to that useful link by Howard.

Recall that the C and C++ standards already define in struct tm:

   int tm_wday;  // days since Sunday — [0, 6]

It might get awkward to ignore this convention.  It is most unfortunate that we have this conflict between C and ISO.  We have to conflict with either C or ISO on this point, and I have no problem with either choice.  Slight preference with conflicting with ISO just because I think C++ programmers are more likely to know about struct tm than ISO-8601.  But I wouldn't loose sleep over either choice.

> My suggestion is to use
> ISo ordering only in functions like date() or make_date().
> 
> But when using slash, as in:
> 
>    date d = day(25) / dec / 2013;
> 
> It is very natural to me. Here in my part of world, d-m-y is the dominant
> format. Otherwise use of '/' itself is of no much use.

Lately I've been recalling that earlier drafts of my 2011 allowed one to specify just the first unit explicitly, and then if you know the 3 date orders, then the other two units are set and can be unambiguously implicit.  Furthermore if the middle unit is specified as day, then the first and last units have to be month and year respectively.  An early review found that confusing, but it did allow for very compact notation.  And perhaps that decision should be revisited too.  Taking your example:

    date d = day(25) / dec / 2013;
    date d = day(25) / 12 / 2013;
    date d = dec / 25 / 2013;
    date d = 12 / day(25) / 2013;
    date d = year(2013) / dec / 25;
    date d = year(2013) / 12 / 25;

All of the above could be unambiguous.  Furthermore:

    date d = 12 / last / 2013;

In practice I have found that I don't mind specifying the first two units that much.  And I have also found that despite the fact that my "natural/cultural" ordering is mdy, I tend to use the other orders quite freely depending upon the context.  For example, if I have a compile-time month and compile time day, or I already have units of day and month, but an int for the year, I'll always use one  of mdy or dmy:

  for (date d = jan/last/y; ...

or:

  for (date d = mon[2]/jan/y; ...

And when I already have a year type, I tend to use that as the first unit:

  for (date d = other_date.year() / jan / 1; ...

I explored the use of operator-() for the date separator, but the operator precedence is problematic for expressions like:

   date d = days(30) + day(25)-dec-2013;

Otherwise that would have lined up very nicely with ISO.

Howard