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.
> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk