Re: System.TimeZone interface unusable?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

| 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 forI
I interpret "local time" as local to the "current" Time Zone. Currently
"current" Time Zone is TimeZone.CurrentZone. If you create a TimeZone object
then that object is the "current" Time Zone.

Although I agree with the gest of your comments. The documentation is
misleading, so the method cannot be truely implemented correctly.

| The definition of Local throughout MSDN still seems to be machine local
Ah! There's the rub! "seems to be", "local time" really needs to be defined
better in relation to what, especially when you start deriving classes...


--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


<nosiren@xxxxxxxxx> wrote in message
news:1135694003.995396.12920@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
| 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: IsDayLightSavingTime doesnt work for 2007 and beyond
    ... ' Example of the TimeZone.IsDaylightSavingTime(DateTime), ... ' Get the local time zone and a base local time. ... Dim localZone As TimeZone = TimeZone.CurrentTimeZone ... ' Create DaylightTime objects for specific years. ...
    (microsoft.public.dotnet.framework)
  • Re: Nasty bug in handling of DateTime.MaxValue & DateTime.MinValue
    ... When a webservice passes a datetime variable it is passed in the local time ... But the receiving client assumes it to be it's local time zone. ...
    (microsoft.public.dotnet.framework.webservices)
  • Re: System.TimeZone interface unusable?
    ... ToLocalTime must be "A DateTime instance whose value is the local time ... as the parameter states "a UTC time". ... serializer documentation is the only other place the Kind property is ...
    (microsoft.public.dotnet.framework)
  • Re: IsDayLightSavingTime doesnt work for 2007 and beyond
    ... ' Example of the TimeZone.IsDaylightSavingTime(DateTime), ... ' Get the local time zone and a base local time. ... Dim localZone As TimeZone = TimeZone.CurrentTimeZone ... ' Create DaylightTime objects for specific years. ...
    (microsoft.public.dotnet.framework)
  • Re: how to get tomorrow date using Date::CALC
    ... Bob wrote: ... > How to convert $tomorrow back to YY-MM-DD format? ... people around the world to read documentation to you. ... local time. ...
    (comp.lang.perl.misc)