[Mono-dev] Time zone problems with DateTime.Parse (patch and bug)
atsushi at ximian.com
Wed Sep 7 13:53:26 EDT 2005
>>>> Test case:
>>>> I think the problem here is that the internal DateTime(bool,long)
>>>> constructor calls tz.GetUtcOffset(this) with the UTC time to get the
>>>> timezone offset before applying it to get local time, but that function
>>>> expects a local time to determine if DST is active. A bit of a
>>>> chicken-and-egg problem, perhaps... ;)
>>> Agreed. But it seems possible to avoid that problem. Can you please
>>> try attached patch? I don't have sane Unix environment and I'm
>>> not in such region that has summer time ;-) It would be even nicer
>>> if you try the entire corlib Nunit tests as well.
>> Cool, that's definitely closer! Unfortunately it's still a bit off;
>> during the doubled hour in the DST transition it's an hour off in the
>> wrong direction. Using output from my test proggy on that bug:
> Okk, based on your help, I found some things. The most important one
> is that there are different basis of TimeZone: UTC and local time
> (there might be other patterns). now I think we need our own
> TimeZone data store, that would store timezone names as well.
> At least DateTime.ToLocalTime() will be rewritten just to invoke
> So, I'll revisit here later. Thanks for all your help, Brion :-)
After some attempt (I think) I could fix TimeZone.ToLocalTime() for
PST/PDT (the attached patch is for bug #75985). However, I have no
better idea than that it just fixes offsets in that timezone, as
I mentioned my concern about the basis difference (UTC or localtime).
So I will have to dig into POSIX timezone design in depth.
And apart from the matter above, I will still have to extend our
locale-builder to support TimeZone name.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the Mono-devel-list