Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-05-05 07:48:53
On May 5, 2013, at 4:36 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
> Le 05/05/13 04:19, Rob Stewart a Ã©crit :
>> On May 4, 2013, at 4:15 PM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
>>> date today();
>> I'd expect to be able to influence the time zone.
> Boost.DateTime provides time zone management, but as far as I know it has been a nightmare to maintain it.
I wouldn't call it a nightmare, but tools are needed to convert from the published data to a format needed for use by a time zone class, if it doesn't do the parsing directly.
> If someone knows of some portable 3pp library that we could include in Boost helping on time zone management I could include it, but developing it is not on my priorities.
Date support is not complete without it. You could define a time_zone class, put the appropriate interface on it, and the implement only UTC and local for now. That would leave room for later support of the rest of the needed things, like DST transitions and historical alterations.
> Maybe someone wants to do it or mentor a GSoC for the next year.
That would be good.
>>> day day() const; // or explict operator day(); the same for the other accessors.
>> I'd expect one or the other. day() is probably better, since day can offer an explicit, converting constructor to get the effect of the operator. That simplifies the date I/F a little.
> Let me show the usage:
> What do you prefer? Couldn't both be provided?
I was presuming both but using the converting constructor for the latter.
> I have one possible non-member addition. I'm trying to see how to compare two dates of different date types.
> Should the user convert explicitly before comparing ?
> days_date d1;
> ymd_date d2;
> if (d1 == days_date(d2))
> if (ymd_date(d1) == d2)
> or should the operator choose the conversion?
> if (d1 == d2)
> This is surely not too important as the user would use the same date type while comparing comparing dates.
Ideally, all date types should be directly comparable. That is, the operator should decide the best means of doing the comparison. This is also cleanly extensible to new date types and is the cleanest notation.
(Sent from my portable computation engine)