Windows Mobile: SetSystemTime and DST, Einstein’s Relativity Theory?

Print This Post Print This Post

Wow, as I first saw this issue, I thought I was facing Einstein’s Relativity Theory.

The issue is simple to explain:
1) The WinMo device has a local time and date within DST
2) You use SetSystemTime to set a new system time and date outside the DST frame
3) The local time changes but DST is still applied!

In concrete example:

GetTimeZoneInformation:
 DaylightSaving-Time:

Bias -60  Daylight-Name: W  Daylight-Bias: -60 Standard-Name: W  Standard-Bias: 0
Standard-Date: 00/10/05 03:00:00, Daylight-Date: 00/03/05 02:00:00

1. Set time inside DST +++++++++++
+++++++++++ TstSetTime ++++++++++++
SetSystemTime:  2010/09/21 10:32:00
GetLocalTime:   2010/09/21 12:32:00
GetSystemTime:  2010/09/21 10:32:00

------------ TstSetTime ------------
2. Set time outside DST ----------
+++++++++++ TstSetTime ++++++++++++
SetSystemTime:  2010/10/31 01:50:00
GetLocalTime:   2010/10/31 03:50:00
GetSystemTime:  2010/10/31 01:50:00

As you can see, local time is 2 hours of, although the data/time is outside DST. You can also see, that the device is in GMT+1 time zone.

Ah, you say this is a known issue. OK, lets do it the microsoft way and Sleep() and set system time again:

3. SLEEP...
4. Set time outside DST 2nd CALL ----------
+++++++++++ TstSetTime ++++++++++++
SetSystemTime:  2010/10/31 01:50:00
GetLocalTime:   2010/10/31 02:50:00
GetSystemTime:  2010/10/31 01:50:00

You are right, now the local time is correct.

Ok, not clear but a workaround. Now go on and set time back into DST:

------------ TstSetTime ------------
5. Set time back inside DST +++++++++++
+++++++++++ TstSetTime ++++++++++++
SetSystemTime:  2010/09/21 10:32:00
GetLocalTime:   2010/09/21 11:32:00
GetSystemTime:  2010/09/21 10:32:00

Again a fault. This time DST is not applied although the date is within DST frame.

Doing the same in Compact Framework is more worst and you will only get valid results with disabled DST.

The best workaround is to disable DST BEFORE you change the system time and then restore DST after changing the system time.

.Net code snippets:

        private DateTime startDateTime = DateTime.Parse("2010/9/24 11:42:00");

        [DllImport("coredll.dll", SetLastError = true)]
        static extern Int32 GetLastError();

        [DllImport("coredll.dll", SetLastError = true)]
        static extern bool SetSystemTime(ref SYSTEMTIME time);
        [DllImport("coredll.dll", SetLastError = true)]
        static extern void GetSystemTime(out SYSTEMTIME lpSystemTime);

        [DllImport("coredll.dll")]
        static extern bool SetTimeZoneInformation([In] ref TIME_ZONE_INFORMATION lpTimeZoneInformation);
        [DllImport("coredll.dll", CharSet = CharSet.Auto)]
        private static extern int GetTimeZoneInformation(out TIME_ZONE_INFORMATION lpTimeZoneInformation);

        private const int TIME_ZONE_ID_UNKNOWN = 0;
        private const int TIME_ZONE_ID_STANDARD = 1;
        private const int TIME_ZONE_ID_DAYLIGHT = 2;

        [StructLayoutAttribute(LayoutKind.Sequential)]
        public struct SYSTEMTIME
        {
            public short wYear;
            public short wMonth;
            public short wDayOfWeek;
            public short wDay;
            public short wHour;
            public short wMinute;
            public short wSecond;
            public short wMilliseconds;
        }
        [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
        public struct TIME_ZONE_INFORMATION
        {
            public int bias;
            [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 32)]
            public string standardName;
            public SYSTEMTIME standardDate;
            public int standardBias;
            [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 32)]
            public string daylightName;
            public SYSTEMTIME daylightDate;
            public int daylightBias;
        }
...
        private bool disableDST(TIME_ZONE_INFORMATION tzi){
            //set wMonth in standardDate to zero
            SYSTEMTIME stStd;
            stStd=tzi.standardDate;
            stStd.wMonth=0;
            //set wMonth in daylightDate to zero
            SYSTEMTIME stDST;
            stDST=tzi.daylightDate;
            stDST.wMonth=0;

            tzi.daylightDate=stDST;
            tzi.standardDate=stStd;
            bool bRes = SetTimeZoneInformation(ref tzi);
            if (bRes)
                addText("*** Disabling DST OK***");
            else
                addText("*** Disabling DST failed***");
            return bRes;
        }

Possibly a good information for all that do TimeSync with a server.

2 Comments

  1. zerodtkjoe says:

    Thanks for the info

  2. Habib says:

    It is not a bug, it is the expected working method according to the documentation:

    “The system uses UTC internally. Therefore, when you call SetLocalTime, the system uses the current time zone information to perform the conversion, including the daylight saving time setting. Note that the system uses the daylight saving time setting of the current time, not the new time you are setting. Therefore, to ensure the correct result, call SetLocalTime a second time, now that the first call has updated the daylight saving time setting.”

Leave a Reply