Boost logo

Boost :

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-05-05 07:35:05


On May 4, 2013, at 7:33 PM, Howard Hinnant <howard.hinnant_at_[hidden]> wrote:

> On May 4, 2013, at 6:15 PM, Anurag Kalia <anurag.kalia_at_[hidden]> wrote:
>
> 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.

I don't know what the ISO convention is, but I know the C convention from struct tm and tools.

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

Interesting.

___
Rob

(Sent from my portable computation engine)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk