On May 5, 2013, at 8:12 PM, Anurag Kalia
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