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

Howard