CF determines Now() based on wrong time

[Alex Feinman [MVP]]

I thought we already complained about this one...
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&th=d07010b10fa7bd8e&rnum=1

"Chris Tacke, eMVP" <cta...@spamfree-opennetcf.org> wrote in message
news:e2ZGvn2s...@TK2MSFTNGP12.phx.gbl...
> The time returned by DateTime.Now does not get properly adjusted when the
> time zone bias is modified programmatically. This is a slightly esoteric
> issue and I think understand how it occurred.
>
> First, let's look at how the clock in CE works:
>
> The system stores the current time in a "system clock" and can either
return
> the local time via GetLocalTime or GMT via GetSystemTime. If you look at
> the CE source for these, you'll see that GetLocalTime returns the system
> clock and GetSystemTime is actually corrected based on the TZ bias. This
is
> counter-intuitive and opposite the desktop behavior.
>
> If you look at the source for the CF (pardon my decompilation), you'll see
> this:
>
> public static DateTime Now
> {
> get
> {
> return new DateTime(GetSystemFileTime() +
> 504911232000000000).ToLocalTime();
> }
> }
>
> private static long GetSystemFileTime()
> {
> InternalSystemTime internalSystemTime = new InternalSystemTime();
> if (!PAL.DateTime_GetSystemTime(ref internalSystemTime))
> {
> return 0;
> }
> else
> {
> return DateToTicks(internalSystemTime.Year - 1600,
> internalSystemTime.Month, internalSystemTime.Day) +
> TimeToTicks(internalSystemTime.Hour, internalSystemTime.Minute,
> internalSystemTime.Second) + (ulong)internalSystemTime.Millisecond *
> (long)10000;
> }
> }
>
> This means that the CF is basing Now() on the System time.
>
> Ok, so this all works fine until we call SetTimezoneInformation and adjust
> the bias. The CE kernel makes no actual time adjustments, so GetLocalTime
> will return the same value as before. GetSystemTime, however, uses the
bias
> to modify it's result. It seems that the CF then uses the bias again.
>
> So if we assume it is now 10:00 AM EST and follow this pseudocode:
>
> DisplayCurrentTimes();
> SetTimezoneBias(-120);
> DisplayCurrentTimes();
>
>
> At the start we'll get:
>
> Local: 10:00
> System: 15:00
> Now: 10:00
>
> After the bias change we get:
>
> Local: 10:00
> System: 12:00
> Now: 7:00
>
> I've attached some VB code that replicates this (though it's somewhat
> convoluted as it run on the PC and under CE).
>
> I get the same behavior under CE 4.1 or CE 5.0
>
>
>
>

[Chris Tacke, eMVP]

We did, but the squeaky wheel gets the grease (at least I hope). This time
they have nice repro steps and code.

--
Chris Tacke, eMVP
Co-Founder and Advisory Board Member
www.OpenNETCF.org
---
Windows CE Product Manager
Applied Data Systems
www.applieddata.net

"Alex Feinman [MVP]" <publi...@alexfeinman.com> wrote in message
news:eV4Xv%233sDH...@TK2MSFTNGP10.phx.gbl...

[Fernando]

Thanks Chris, Alex for taking the time to look into this on detail.
A couple of things I would like to remark though:

1) NETCF V1 doesn't pick up changes on the TimeZone during the applicattion
lifetime, that's the reason why we don't support the method
ClearCacheData() on V1, the scenario of handling TimeZone changes during
the lifetime of the app is not supported by design.
2) The only way to update the CurrentTimeZone is to restart the app. New
appdomains created after the change will pick up the new
TimeZoneInformation also.

So, taking that into consideration, in the scenario that you described the
main problem is that the offsets used by WinCE and NETCF are different,
since they both have different TimeZoneInformation data.
So, if you use SystemTime as the base for DateTime.Now, this value will be
out of sync with native local time, but if you do the other way ( desktop
behavior), you can run into the following type of discrepancy:

DateTime.Now.ToUniversalTime() --> wrong, it uses old offset.

Also, in both cases any conversions produced inside the BCL's will use the
old offset.

I do agree that using GetLocalTime() for DateTime.Now and GetSystemTime()
for DateTime.UtcNow seems to be the better aproach, but still the best way
to resolve this issue is to call ClearCacheData, so, any votes on
implementing this API for our next version? please let me know what you
think.

Hope this helps,
Fernando

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
| From: "Chris Tacke, eMVP" <cta...@spamfree-opennetcf.org>
| References: <e2ZGvn2s...@TK2MSFTNGP12.phx.gbl>
<eV4Xv#3sDHA...@TK2MSFTNGP10.phx.gbl>
| Subject: Re: CF determines Now() based on wrong time
| Date: Tue, 25 Nov 2003 15:23:53 -0400
| Lines: 110
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <#$Y9qm4sD...@TK2MSFTNGP12.phx.gbl>
| Newsgroups: microsoft.public.dotnet.framework.compactframework
| NNTP-Posting-Host: nat2.applieddata.net 64.72.200.61
| Path:
cpmsftngxa07.phx.gbl!cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.
phx.gbl
| Xref: cpmsftngxa07.phx.gbl
microsoft.public.dotnet.framework.compactframework:39342
| X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

[Chris Tacke, eMVP]

It would make more sense to me to actually implement a way within the CF to
modify the timezone information call ClearDataCache. This would allow the
CF to internally do whatever it needs to make sure that Now() is correct and
would remove the need for P/Invoking and the need to know that after
adjusting the timezone you have to . While the team is at it, they might as
well implement a way to set the clock too.

--
Chris Tacke, eMVP
Co-Founder and Advisory Board Member
www.OpenNETCF.org
---
Windows CE Product Manager
Applied Data Systems
www.applieddata.net

""Fernando"" <fern...@online.microsoft.com> wrote in message
news:VrDxRH9s...@cpmsftngxa07.phx.gbl...