views:

94

answers:

4

I made a simple web service which worked nice with few systems that it was deployed. Now the date from Oracle causes trouble on other system.

Some info:

Our own methods that accesses oracle returns dates as string in format 15.09.2010 13:15:00 (note year in 4 digits)

System working:
-DateTime.ToSring() produces 16.09.10 14:15:49 (used in log-file, note year in 2 digits)
-TryParse(string s, out DateTime result); returns true with string 15.09.2010 13:15:00
-System.Globalization.CultureInfo.CurrentUICulture.Name has value "en-US"

System NOT working:
-DateTime.ToSring() produces 9/16/2010 1:25:51 PM  (used in log file)
-TryParse(string s, out DateTime result); returns false with string 15.09.2010 13:15:00
-System.Globalization.CultureInfo.CurrentUICulture.Name has value "en-US"

So my questions are:

  1. What is different with these 2 systems?
  2. What is the best way to make this code universal (i know i can use formatter for DateTime.TryParse and DateTime.ToString() )
A: 

I can't say what is the difference between the two. But, If you are planning to convert a string to DateTime better do it from Ticks.

DateTime.Ticks will provide you with a long value that you can save as Int64 or print to a text file. If you still want to look at the text file and understand the time you can print both.

Ticks are universal and will work under any condition and collation.

Gilad
+3  A: 

Chances are that the date and time formats on the two machines are configured differently (in Control Panel -> Regional and Language Options -> Formats).

If you want to make this code universal then you should specify an explicit format when using ToString, TryParse and any other methods that convert a DateTime to/from text; and use UTC. Your safest bet would probably be one of the ISO-8601 formats; for example yyyy-MM-ddTHH:mm:ssZ.

LukeH
thanks luke! Regional and Language Options was the key... Estonian and Finnish are the same so it worked there by luck. Really bad design/implementing i must admit.
matti
+1  A: 

Our own methods that accesses oracle returns dates as string in format

That strikes me as your main problem. Why are you converting values into strings to start with? Use parameterized queries etc, and you shouldn't need to deal with string values at all. Just return DateTime or DateTimeOffset.

You could make sure that you always parse/format with a very specific format string and culture... but it's best to avoid performing the conversion in the first place.

Jon Skeet
naturally that is the best option but unrelated to my question. methods use legacy c-code that is called from C#. using that was naturally a mistake but i cannot chage the db-layer anymore :( in future i use only ADO.NET
matti
A: 

It depends.

  • For formatting , it is determined by the thread current locale. Point.

  • This gets normally pre-initializd with the locale of the user starting the application.

  • I think for web, it is determined by THE BROWSER transmitting the languages it wants. That said, this is unsure - could also depend on a setting in web.config.

Anyhow, if you want SPECIFIC formatting, then ASK FOR IT. CultureInfo.InvariantCulture etc. can be handed into all formatting functions, and - last resort - the thread's current culture can also be changed.

TomTom