Re: System.TimeZone interface unusable?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hi Jay,

Thanks for the reply.

> Using ILDASM, it appears that TimeZone.ToLocalTime in .NET 2.0 is hard wired
> to a concrete implementation class. IMHO a very bad no no in OO.

My thoughts exactly.

> You should be able to override TimeZone.ToLocalTime itself and have the
> behavior you expect.

I would say this is true, but I have to consider the contract of the
base class. According to the MSDN documentation, the return value of
ToLocalTime must be "A DateTime instance whose value is the local time
that corresponds to time... Local time is the date and time on the
computer you are using." Therefore, overriding ToLocalTime to return
anything other than machine local time breaks the contract for
ToLocalTime, and will cause incorrect results for someone expecting the
documented base class behavior.

> The quirk/caveat is going to be what to do with DateTimeKind.Local on input
> to MyTimeZone.ToLocalTime. My sample only allows Utc or Unspecified date
> time values, as the parameter states "a UTC time". Considering that the time
> parameter maybe in a different time zone then the this time zone, IMHO the
> exception is the "better" choice. Alternative if the input is already Local
> then one could simply return it "As is", as its already local...

The definition of Local throughout MSDN still seems to be machine local
time, so although there are problems as you have specified, they are
different than you have mentioned. Most notably, any DateTime that is
not UTC or machine local time must have a Kind of
DateTimeKind.Unspecified. Regardless, it seems perfectly sensible for
ToLocalTime() to assume a UTC parameter and for ToUniversalTime() to
take a "native time" parameter (avoiding the phrase "local time" for
obvious reasons). Personally, I suspect that the addition of
DateTime.Kind to the framework was not for the benefit of the TimeZone
class at all.

It's my understanding that, prior to .NET 2.0, the XML Serializer made
the fundamentally flawed assumption that all outoing dates were in
machine local time and all incoming dates were in UTC. Since the
serializer documentation is the only other place the Kind property is
mentioned, I have to conclude that DateTime, a core component of the
framework IMHO, has been hijacked to fix mistakes made in the XML
Serializer. If that is true, then this really is a nasty little hack.
Even the new documentation for DateTime reads like raw hackery: "Prior
to the .NET Framework version 2.0, the DateTime structure contains a
64-bit field composed of an unused 2-bit field concatenated with a
private Ticks field." You can almost hear Jon Lovitz saying, "I meant
to do that... yeah, that's the ticket."

As it stands, I've pretty much concluded that the documented interface
for System.TimeZone is fundamentally broken, and am moving on with my
own base class with a similar interface but a more sensible contract.

Thanks,

Russ

.

Relevant Pages

  • Re: Web services and incorrect handling of time zones in DateTime
    ... You are not the first one writing this, I think that it is an error by design. ... when the SOAP message contains datetime like ... exactly the same time as previously, but in UTC), it becomes DateTime ... the UTC time should be converted to local time ...
    (microsoft.public.dotnet.general)
  • Re: DateTime about the zone
    ... You mean it's 093429 local time in France? ... That means that 073429 is UTC. ... Thanks, fine, seems to be easier to do with Time than with DateTime ...
    (comp.lang.ruby)
  • Timezone and ISO8601 struggles with datetime and xml.utils.iso8601.parse
    ... I am trying to convert a local time into UTC ISO8601, then parse it ... How can I convert this into UTC? ... the date is converted into UTC on construction of the datetime object, ...
    (comp.lang.python)
  • Re: UTC conversion from different time zones
    ... but in my idea is the time in Net not real calendar based. ... But if you take something which is already UTC (because you've called ... I find the dateTime pretty good. ... DateTime had no idea whether it was a local time or a universal time - ...
    (microsoft.public.dotnet.general)
  • Re: System.TimeZone interface unusable?
    ... | ToLocalTime must be "A DateTime instance whose value is the local time ... Local time is the date and time on the ... Therefore, overriding ToLocalTime to return ... The documentation is ...
    (microsoft.public.dotnet.framework)