by Michael S. Kaplan, published on 2008/02/26 10:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/02/26/7897102.aspx
Brian was once telling me about a meeting of various folks from the .NET Framework. Anders was there (yes, that Anders!).
Anyway, the meeting started in the normal way but people found themselves rat-holing on some very obscure technical issues. It was spinning further and further out of control into scenarios that were very obscure, bordering on invented or even imaginary. It was easy to follow the logic if you were there, but otherwise this shared form of associative linkage would be impossible to grok.
Finally, Anders stopped everyone, and asked whether anyone knew precisely what was being discussed at the moment. There was an embarrassed pause, as everyone realized that no one did.
And then Anders ended the meeting.
Apropos of nothing, perhaps. But I'll let you decide. :-)
The unrelated question that Rags asked yesterday was straightforward enough:
DateTime.ParseExact (apparently) does a case-insensitive comparison of the names of the days and months. Is there a way to make it do case-sensitive comparison?
I’m dealing with parsing of date time strings given in RFC 1123 format. I use DateTime.ParseExact & pass ‘R’ to the format string to indicate RFC1123Pattern for date time format. However the following string is being considered as valid even though it’s invalid because the name of the day is case-sensitive (& must be Sun not SUN) according to RFC.
"SUN, 06 Nov 1994 08:49:37 GMT"
Thanks
Malcolm stepped up with some information from the referenced standard that helped understand the urgency of the request:
RFC 822, which RFC 1123 references re Date/Time formats, specifically states:
<<
3.4.7. CASE INDEPENDENCE
Except as noted, alphabetic strings may be represented in any
combination of upper and lower case.
...
When matching any other syntactic unit, case is to be ignored.
For example, the field-names "From", "FROM", "from", and even
"FroM" are semantically equal and should all be treated ident-
ically.
>>
Ah good, so that takes care of that. :-)
Or maybe not?
Rags replied back:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3 states the following in the context of HTTP
All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for time zone, and MUST be assumed when reading the asctime format. HTTP-date is case sensitive and MUST NOT include additional LWS beyond that specifically included as SP in the grammar.
Thanks
Let's pretend that RFC1123 and RFC2616 are tied together despite no such reference and that RFC1123 and RFC822 are not despite having one, and then take this one around the dancefloor three times. :-)
Well, if one calls DateTime.ParseExact then one will have a DateTime.
One could take that DateTime and then then turn around and call DateTime.ToString("R") on it.
And then compare the resulting string to the original one before the parse, using whatever means one wishes to use!
I would definitely recommend against an Ordinal comparison here, since út (U+00fa U+0074) == út (U+0075 U+0301 U+0074) thanks to Unicode canonical equivalence, and you would almost certainly want them to be considered equal to each other. Since they are meant to be considered equal to each other.
If you wanted to use Ordinal comparisons in spite of all that, you could always normalize the strings, I suppose....
Of course that seems like a lot of work, but then that's what artificial requirements often bring to the party.
I am going to take this opportunity to point out that we are so far from the original scenario that the methods may as well be called TryParseImaginary and ToStringFictional. The blog (though not the Blog) has lost sight of what it is trying to say.
And although I'm not Anders1, I am now going to thank you all for reading this far, and end the blog post.
1 - Well, I suppose I could claim that by virtue of being the owner and sole author of SiaO that I am the Chairman, CEO, COO, CTO, CFO, VP, TF, and DE of the entire Blog, but that is really kind of silly, you know? :-)
This blog brought to you by ú (U+00fa, aka LATIN SMALL LETTER U WITH ACUTE)