The XML standard being used does include the timezone suffix +12:00/+13:00, it is just that the current clients ignore that and assume the time is local time, so we want to adhere to the standard in case clients come on board that DO handle the timezone.
Of course our code is set up to revert to UTC when the client seems to be able to accept it because it produces it. -- Regards, Mark Hurd, B.Sc.(Ma.)(Hons.) On 4 February 2011 12:29, David Kean <[email protected]> wrote: > Is there any reason you can't just the DateTime's convert to their local time > before you send it back? Ie By calling TimeZoneInfo.ConvertTime(DateTime, > TimeZoneInfo)? > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Wallace Turner > Sent: Thursday, February 03, 2011 5:55 PM > To: ozDotNet > Subject: Re: Non-standard time zone handling > > On 4/02/2011 9:27 AM, Mark Hurd wrote: >> Then the client noticed their existing clients ignore the UTC of the >> Xml and assume it is local time, so we needed to switch to their local >> time, not our server's. (We're not in the position to say their >> clients are in the wrong.) > > But they are? I think any change other than changing the client is going to > be a massive headache. > > Perhaps it needs to be sold to them, eg, if they parse it as UTC then they > can display it any timezone the user wishes. >
