Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / Internationalization / November 2004

Tip: Looking for answers? Try searching our database.

DateTime.Parse for yyyyMMdd

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
René Titulaer - 24 Nov 2004 12:37 GMT
Dear all,

i have a date in the format yyyyMMdd. When I try to parse this I get the
following error: string was not recognized as a valid datetime.

I use the following code:

CultureInfo culture = new CultureInfo("en-US");
culture.DateTimeFormat.DateSeparator = string.Empty;
culture.DateTimeFormat.ShortDatePattern = "yyyyMMdd";

// Here the error occurs:
DateTime date = DateTime.Parse("20041123", culture.DateTimeFormat);

Thanx,
René
Benny Tordrup - 26 Nov 2004 10:21 GMT
René,

Why don't you use the DateTime.ParseExact() method?

Best regards,

Benny Tordrup

> Dear all,
>
[quoted text clipped - 12 lines]
> Thanx,
> René
René Titulaer - 26 Nov 2004 10:35 GMT
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é

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.