views:

291

answers:

4

I'm trying to parse a date/time string using DateTime.ParseExact. It works everywhere, except on one machine - it just will not parse on that machine. The question is: Why? What could be different on that machine so that it will cause this behaviour?

Here are some things that I've already looked at:

  • The CultureInfo is passed to DateTime.ParseExact, namely CultureInfo.InvariantCulture
  • The regional settings on the rogue machine is the same as the settings on a machine where the parsing works.
  • Yes, the string is in the correct format, which is dd/MM/yyyy HH:mm:ss
+1  A: 

It's really hard to guess what the solution could be without exception information (which Marc Gravell asked about) and/or some sample code.

In my experience, i've had problems with date/times because of cultural issues. You've said you've already had a go at hard-coding that.

what about the actual culture the process is being run within? if this code is in an asp.net website, the culture is set based upon the users browser settings (passed along in the request).

try doing this in your code to hard-code the current threads culture to see if this help as a way to debug this issue further.

// Replace the culture with whatever you required.
System.Threading.Thread.CurrentThread.CurrentCulture = 
    CultureInfo.CreateSpecificCulture("en-GB");

tell us what happens when you try that? ** I hate entering answers when we don't have enough info. this is more a suggestion than an answer :)

Pure.Krome
A: 

Make sure the region settings on the machine that doesn't work matches the machines that do work. To avoid issues like this in the future, specify the culture when parsing.

the OP said he/she already checked those settings. Make sure you read the entire post.
Pure.Krome
A: 

I agree with Pure.Krome that more info is needed. To that end, questions:

  • What exception is being thrown?
  • Which method overload are you calling, and what, exactly, are you passing to it?
  • Have you verified that the .NET runtime version is the same on all boxes? Including Service Pack Version?
  • Is the string you're parsing generated by your program or does it come from an outside source? If it's external, have you verified that the string isn't inappropriately escaped in some way on the rogue box? Perhaps the version of whatever program creates the string is out of date and has a bug in it.
Randolpho
+5  A: 

I always find that regional settings can be tricky, and you can never assume that the users of your application will even have their machines setup correctly in the first place!

A catch-all that I've been using to parse dates in if they have to be strings is to parse it in the "dd/MMM/yyyy" format, e.g. "14/JAN/2009" will translate nicely no matter what the settings are.

Incidentally this trick also works with SQL Server as well :)

keith
Thanks, that worked for me too
csjohnst