Wednesday, July 25, 2012

Formatting DateTime values from another timezone

For a while I've been battling with formatting DateTime values generated in another timezone using .NET's DateTime string formatting capabilities. For instance, I have an XSD datetime value of "2012-07-26T00:00:00+10:00" (generated in Australian Eastern Standard Time), but I'm in a different timezone (Australian Central Standard Time, +09:30). If I parse the XSD datetime value into a .NET DateTime, it automatically gets converted to my timezone: "2012-07-25T23:30:00+09:30". If I then wanted to get just the date value (in the original timezone), I'd actually get the wrong date!!!

Today I finally stumbled across the DateTimeOffset class, thanks to

Basically this struct preserves the datetime in its original timezone, including offset. So for example (from LINQPad):

So, if you want to work with dates in their original timezone, DateTimeOffset is your friend!! This can be particularly important when you're working with XSD datetimes as you commonly do in BizTalk solutions, and need to format datetime values, but without converting between timezones.

Error importing WSDL file into BizTalk solution

Today I was importing a WSDL file provided by a third party web service into a Visual Studio BizTalk solution using the "Metadata Files" option in the BizTalk WCF Service Consuming Wizard and ran into the following error:

"Unable to add metadata file ... (System.InvalidOperationException) There is an error in XML document (1, 40). (System.Xml.XmlException) Name cannot begine with the '.' character, hexadecimal value 0x00. Line 1, position 40."

I opened the file and took a look at line 1, position 40: looked perfectly fine to me. The only thing I noticed when I opened the file was that the file's encoding property (in the Visual Studio properties window) changed when the file was opened in Visual Studio: from Unicode, to UTF-8 (consistent with the encoding specified in the xml declaration).

I saved the modified file and re-ran the BizTalk WCF Service Consuming Wizard, and the file imported fine. I then re-ran the Wizard again with the original file, and the same error occurred. I also tried the wizard using the "Metadata Exchange" option (to browse directly to the live WSDL) and encountered the same error.

I can only conclude that the original WSDL file was generated in the Unicode encoding, which the BizTalk WCF Service Consuming Wizard didn't like, presumably as it wasn't consistent with the encoding specified in the XML declaration.

Anyway, hope this might help someone out there.