Brent Laabs via RT wrote: >http://design.perl6.org/S32/Temporal.html#line_97 says that DateTime.new >accepts RFC 3339 strings, not ISO 8601. It should probably accept >both. One of the "wrong" formats in particular, the timezone -0000, >is required by RFC 3339.
If you specifically intend to accept RFC 3339 format then OK, that's grounds to accept "-00:00". But the documentation for the constructor should then say that it's accepting RFC 3339 format as well. In any case, RFC 3339 doesn't account for the other two faults. >The purpose of DateTime.new is not to validate your datetime >format, Input validation is a useful feature, and is actually being advertised by the documentation. If you don't intend to provide a validation service then the documentation mustn't advertise it. But that would be a pity; you're *nearly* performing the useful validation already. >And I imagine that most of the users will agree that we should apply >Postel's law here The Postel principle doesn't properly apply here. It's a strategy to deal with ambiguous specs, as many of the early IETF RFCs are. The liberal/conservative split covers the area of ambiguity, thus covering up the spec author's mistakes. Where the spec is unambiguous, however, there is no basis for this kind of liberality. Accepting things that are unambiguously prohibited by the spec isn't a pragmatic approach to problematic circumstances; it's just gratuitous deviation from proper behaviour. ISO 8601, for all its readability issues, is quite clear about what is permitted, and the things I have called out are unambiguously prohibited. In any case, this code doesn't look like intentional liberality: it's not even a misguided attempt to apply the Postel principle. It looks like it's just sloppy verification. Postel has only been invoked post-hoc to excuse the sloppiness. >Rejecting ticket. As I said in an earlier message, if the code is not a bug then the documentation is. In this ticket I'm reporting the mismatch between code and documentation. Rejecting the ticket doesn't make sense, unless you're rejecting my contention that there is such a mismatch or that the mismatch is a problem needing rectification. Are you? -zefram
