Thanx for your reply,
To be honest this was not really my problem but I did try to understand date
formatting and then I ran into this problem.
Can you please look at my original problem. I have a xml with a date. When I
read it into a dataset with ReadXML I get a datetime conversion error (the
column is defined as xs:date in the dataset schema). The format is
"yyyyMMdd". I did try to solve the error by setting the cultureinfo of the
current threat, my code:
CultureInfo culture = new CultureInfo("en-US", false);
culture.DateTimeFormat.DateSeparator = string.Empty;
culture.DateTimeFormat.ShortDatePattern = "yyyyMMdd";
culture.DateTimeFormat.LongDatePattern = "yyyyMMdd";
System.Threading.Thread.CurrentThread.CurrentCulture = culture;
System.Threading.Thread.CurrentThread.CurrentUICulture = culture;
taskdata.ReadXml(reader, XmlReadMode.Auto);
ReadXml() uses XMLConvert to do the conversion, it looks like XMLConvert
can't convert a string with format yyyyMMdd to a date.
Thanks,
René
> René,
>
[quoted text clipped - 20 lines]
> > Thanx,
> > René
Michael (michka) Kaplan [MS] - 26 Nov 2004 17:49 GMT
Benny's answer (which is a very good one!) can give some insight into the
two very different approaches that these two methods (Parse and ParseExact)
take to do their formatting -- which I think is at the root of your
question....
There are people (including me!) who find problems with the Parse method for
dates. Rooted in COM's "evil date parsing" behavior, it is an improved
version of going down a road that those people do not like. This road leads
to less performant code that for every customer who loves that it parsed
their dated will find another who will be unhappy that it missed an entirely
reasonable format. You can see the same problem to a greater degree if you
change the Regional Options settings on a VB <= 6.0 application (COM was
incredibly forgiving until all of the sudden you found a case where it was
not).
By trying to work for everyone, there will be four groups:
(1) those who are unhappy,
(2) those who are happy,
(3) those who are happy now but will be unhappy when they find out
how screwed up their wrong data is due to incorrect parsing.
(4) those who are unhappy now since the code that used to work in
VB5 or VB6 does not work since the parsing changed.
ParseExact has a goal that is more along the lines of "I gave you the
format, now I will give you the strings in that format; just do the job."
This makes it faster and more exact as a semantic, and as such is much more
suited if the flexibility of the other method is not desired....
It is probably good both exist and it would be nice (in my opinion) if
everything that worked on the latter would work on the former, though I
understand that is yet another scenario for Parse and a chance to slow it
down further (as each new scenario does).

Signature
MichKa [MS]
NLS Collation/Locale/Keyboard Technical Lead
Globalization Infrastructure, Fonts, and Tools
Microsoft Windows International Division
This posting is provided "AS IS" with
no warranties, and confers no rights.
> Thanx for your reply,
>
[quoted text clipped - 47 lines]
> > > Thanx,
> > > René