OK we're in a situation similar to the StackOverflow question: http://stackoverflow.com/questions/2939188
We have an existing code base that used UTC throughout and just relied on the standard XmlSerialization of DateTime. 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.) It seems the "correct" and supported solution is to refactor all our DateTimes to DateTimeOffsets and write our own XmlSerialization classes because the default doesn't cut it. It was easier to get the server time zone to be the client's local time, then the standard XmlSerialization produces the right results with non-UTC DateTimes. But we didn't want to change our server's time zone to that of the client. However, .NET's time zone is stored in only two places, both of which only allow resetting to "unset" and setting to the computer's current time zone. I just produced code to setup a time zone that is not the computer's current time zone and place that in the two places. As I said I don't use any other private APIs, just simply allow a "ReadOnly" property, with a "set" internal to the get, to receive a value the internal set can't provide itself without us momentarily setting the O/S time zone to the time zone we want to use. And this is a "web service" (a web site expecting and emitting Xml, but not using SOAP or any other standard) so it is a single install. (We will be moving it to a Win2008 server from a Win2003, but we're expecting to stay with .NET 3.5(2.0).) -- Regards, Mark Hurd, B.Sc.(Ma.)(Hons.) On 3 February 2011 14:51, David Kean <david.k...@microsoft.com> wrote: > *DO NOT* rely on private implementation details of .NET, we are free to > change these in any release (be it hotfix, security update, GDR, service pack > or full release). When I'm working on these types, be it fixing a bug or > adding features, I don't want to have to (and I don't) worry about what > customers I'm going to break by changing things that we never documented or > guaranteed. You should also be aware that we don't ship the exactly same > changes on all platforms, for example, Windows 7 shipped with a version of > .NET 2.0/3.5 that is not available on any other platform, I know we made > changes to private implementations on that platform that broke some > customers, so who says that you application won't break on other or future OS > versions? > > Let's figure out a way of doing this without needing to rely on updating > private fields. What exactly are you trying to do? What are you hitting that > requires you to update the CurrentTimeZone? > > -----Original Message----- > From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On > Behalf Of Mark Hurd > Sent: Wednesday, February 02, 2011 6:09 PM > To: ozDotNet > Subject: Re: Fwd: Red Gate will be charging $35 for .NET Reflector > > No, as I said I had to update two private fields. Do you expect the time zone > stuff in .NET 2.0(3.5) to be updated in any service packs? > > In any case it is better than any of the public API solutions I could find > that require you to use either UTC or your computer's local time zone. I know > DateTimeOffset can be used for other time zones but the XmlSerialization of > those is too much work. > > IF a service pack breaks the two private fields I'm updating we'll review the > situation. > > Of course you could be asking for legal (licensing) reasons and that's a > whole 'nother story, cause I believe we're not allowed to reflect the > framework, as that would be a form of reverse engineering which is expressly > disallowed. I believe the out here is local laws allow it when using it to > work in with existing systems, like some client's request to work with their > time zone. > > On 3 February 2011 11:48, David Kean <david.k...@microsoft.com> wrote: >> I'm hoping that you did that by calling only public API and not taking a >> dependency on anything private... >> >> -----Original Message----- >> From: ozdotnet-boun...@ozdotnet.com >> [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Mark Hurd >> Sent: Wednesday, February 02, 2011 5:14 PM >> To: ozDotNet >> Subject: Re: Fwd: Red Gate will be charging $35 for .NET Reflector >> >> On 3 February 2011 11:22, Arjang Assadi <arjang.ass...@gmail.com> wrote: >>> Same as Silky said, what is used for? >> >> Well I just used it to determine what I would need to do to change the time >> zone in .NET only, rather than changing the computer's time zone. >> >> And seeing as this is a 2.0 project I'm fairly happy with the results (only >> two private fields updated). I.e. I don't expect any future service packs to >> completely change the time zone handling. >> >> As such I'll probably pay for a new .NET Reflector, but only when the free >> one gets VB.NET ByRef arguments right. > > (BTW I don't like mixing top and bottom posting, but I don't have time to fix > David's post within mine at the moment.) > > -- > Regards, > Mark Hurd, B.Sc.(Ma.)(Hons.)
