Convert.tostring(datetime) Yielding Uk Format Instead Of Us
Solution 1:
Why do you not force the format of the DateTime.ToString() using the culture you specifically want-- or specify a custom formatting rule that matches what your SQL functions expect?
For custom formatting you can look here or for culture specific formatting, you can look here
Solution 2:
Is it possible that the service is running under an account which has the wrong regional settings?
If so, then perhaps these instructions from Microsoft might apply.
Solution 3:
I don't believe there is anything in a DateTime beyond a simple 64-bit integer - basically it's the date/time in ticks, and the "kind" encoded in the top couple of bits. So creating a new DateTime is created locally. In other words, I'm afraid I doubt your claim about what happens when "the same type of object is created locally".
That's where I'd start investigating - get rid of the database call, but just log the result of calling Convert.ToString(serializedDateTime) and Convert.ToString(new DateTime(2011, 7, 25)) (as an example of a date where the string representation makes it obvious which way round things are). I'd be really surprised if you can get that to give two different date formats - one for the value which had been deserialized and one for the value which was created locally.
What "kind" of DateTime do you get after deserialization (i.e. the result of fetching the Kind property)? With that information you should be able to construct an exactly equal DateTime value.
Post a Comment for "Convert.tostring(datetime) Yielding Uk Format Instead Of Us"