Boost logo

Boost :

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

On May 5, 2013, at 8:12 PM, Anurag Kalia <anurag.kalia_at_[hidden]> wrote:

>> Is this being considered for field types, serial types, or both?
>> The reason I ask is that all serial values are valid dates, at least those
>> in range, and we can make the range as big as we want. It is only the
>> field types that are problematic when day, month, or week is out of range.
>> Howard
> The problem with this function is that it can give us a false sense of
> security. If we ask it to make an unchecked date "31-feb-2013", it would
> gladly do it for us. With field representation, we can catch it. But with
> serial representation, it would make a valid but wrong date! I don't think a
> valid date that the user didn't ask for is really a valid date, is it?

You have stated well my concern. In order to spread this to serial_date, serial_date would need to carry an extra bool, or at least an extra bit, which means: came from untrusted source or not. And that would compromise the goal of the serial_date day arithmetic being no more expensive than integral arithmetic. It would also mean that serial_date is no longer just a simple chrono::time_point.

If validity checking is strictly confined to field types, that seems reasonable. But extending it to serial types seems problematic. Once serial, the value is a valid date unless metadata says otherwise. And metadata in a date type has a less-than stellar history. ;-)


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