While doing some work with JSON payloads being received in BizTalk we came across the interesting fact the the BizTalk JSON Decoder will in some situations change the time zone that the date-time was expressed in, even if we did not have a schema that specified these fields as being a date-time (either no schema or the field defined as a xsd:string)

For example, with the following payload going through a BizTalk Receive Pipeline with a JSON decoder.  All the date1 fields are the same time, expressed in different time zones, and all the date2 are equivalent to each other.

{
"ZuluT_date1": "2016-07-23T00:45:40.000Z",
"TZM10_date1": "2016-07-22T14:45:40.000-1000",
"TZP00_date1": "2016-07-23T00:45:40.000+0000",
"TZP12_date1": "2016-07-23T12:45:40.000+1200",
"ZuluT_date2": "2016-01-23T00:45:40.000Z",
"TZM10_date2": "2016-01-22T14:45:40.000-1000",
"TZP00_date2": "2016-01-23T00:45:40.000+0000",
"TZP13_date2": "2016-01-23T13:45:40.000+1300",
}

The output will be

<ns0:Root xmlns:ns0="http://scratch/JSON">
 <ZuluT_date1>2016-07-23T00:45:40Z</ZuluT_date1>
 <TZM10_date1>2016-07-23T12:45:40+12:00</TZM10_date1>
 <TZP00_date1>2016-07-23T12:45:40+12:00</TZP00_date1>
 <TZP12_date1>2016-07-23T12:45:40+12:00</TZP12_date1>
 <ZuluT_date2>2016-01-23T00:45:40Z</ZuluT_date2>
 <TZM10_date2>2016-01-23T13:45:40+13:00</TZM10_date2>
 <TZP00_date2>2016-01-23T13:45:40+13:00</TZP00_date2>
 <TZP13_date2>2016-01-23T13:45:40+13:00</TZP13_date2>
</ns0:Root>

All the date1 fields apart from the Zulu time are expressed in the local date-time zone (+12 for New Zealand Standard Time and all the date2 apart from the Zulu time are expressed in the locate date-time zone of +13 for New Zealand Daylight saving time).

In our case the end system wanted it in New Zealand time anyway, so not a problem, but it may cause an issue in other scenarios.

Advertisements