none
Daylight savings time jumping a head one hour RRS feed

  • Question

  • Hello,

    I am using an ARM based platform running CE Compact 2013.  We have an issue where our real-time clock is jumping an hour ahead.  This is happening when ever we push a WINCE OS upgrade to our devices.  I have been doing some digging with debugger, what I am finding is whenever we do a OS update (replace nk.bin) on our device the registry information is being reset to out of the box.  If this update happens during the months of daylight savings the DST servers push the RTC forward an hour.  This is because something in the OS says that the DST transition hasn't yet happened, then make it happen, even although it already happened while the device had its previous OS build in it.

    Where in the registry is this information stored?  I have had a look with the debugger and have noticed that there is a call to GetTimeZoneInformation(...) function in C:\WINCE800\private\winceos\COREOS\core\dll\time.c  the decision of weather transition is made depends on the value of UserKInfo[KINX_TIMEZONEBIAS] is.  But that is as far as I can drill into the Wince kernel.   Where is UserKInfo initialised?    I do have some NV data structures that I can preserve during OS (nk.bin) updates, but first I need to know where UserKInfo[KINX_TIMEZONEBIAS] is modified, or how I can gain access to it.

    Your help would be much appreciated.

    Andrew


    Andrew Meek

    Monday, March 27, 2017 3:38 AM

Answers

  • Hi Andrew,

    My first thought was to ask Does your image have the "HomeDST" value set to "1"?  See https://msdn.microsoft.com/en-us/library/ee488379.aspx but I am now thinking that is not the issue.

    I have seen similar behavior on a Windows device that has an update from a timezone service from the network because it was actually getting the data from a different timezone based on the service provider location rather than the device itself but that was always 1 hour off, DST or not.

    There is an interesting discussion around the setting for the next DST from 2012 that might be what you are hitting. https://social.msdn.microsoft.com/Forums/en-US/9ed8db88-c19f-41d1-9d99-65fd37c7270f/wince6-daylight-saving-time-issue-during-power-off?forum=winembplatdev

    As your setting are volatile I think you are seeing what Paul saw.  Devices with non-volatile registries will never see this issue as the setting would be preserved between updates (Like with Windows Mobile 5.x & 6.x)

    Sincerely,

    IoTGirl 


    Monday, March 27, 2017 5:45 PM
    Moderator
  • I can't exactly remember what this was for, but I seem to remember we had a similar problem and this fixed it. If you need more info I can go back and see what our version control system says about this registry key:

    ; To make timezones work properly we enable the default timezone info
    [HKEY_LOCAL_MACHINE\init\BootVars]
        "KTzBias"=hex:01,00,00,00,E0,01,00,00,A4,01,00,00

    Add that to your platform.reg file and see if it makes the issue go away. Otherwise follow Paul's advice.


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: https://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    NXP Proven Partner
    https://guruce.com
    Consultancy, training and development services.

    Interested in WEC on i.MX6?
    Get the only 100% stable and best performing i.MX6 BSP for WEC7 and WEC2013 here: https://guruce.com/imx6

    • Marked as answer by Andrew Meek Friday, March 31, 2017 3:42 AM
    Tuesday, March 28, 2017 7:35 PM
    Moderator
  • Andrew,

    Sorry, I don't have notes revealing the right answer. Here's what I'd do, however:

    1. Export HKLM and HKCU to your PC using remote registry editor. This is your baseline.

    2. Using a quick bit of C code running on the target, change the DST flag's setting. To do that, you'd call GetTimeZoneInformation() passing a suitable structure pointer and saving the return value. You should receive either TIME_ZONE_ID_STANDARD, or TIME_ZONE_ID_DAYLIGHT from the call. We'll reverse that below.

    3. Enhance your C code using the return value from GetTimeZoneInformation() and calling SetDaylightTime(). If TIME_ZONE_ID_STANDARD was received, pass "1" to SetDaylightTime(); if TIME_ZONE_ID_DAYLIGHT was received, pass "0" to SetDaylightTime(). We're inverting the daylight flag.

    4. Export the same registry branches above to your PC. You'll difference before and after to figure out where in the registry the current daylight flag is stored, if at all.

    Best I can remember, the flag was stored under HKLM/Services/TimeSvc, but that was a while back!

    Paul T.

    • Marked as answer by Andrew Meek Friday, March 31, 2017 3:42 AM
    Monday, March 27, 2017 10:07 PM

All replies

  • Hi Andrew,

    My first thought was to ask Does your image have the "HomeDST" value set to "1"?  See https://msdn.microsoft.com/en-us/library/ee488379.aspx but I am now thinking that is not the issue.

    I have seen similar behavior on a Windows device that has an update from a timezone service from the network because it was actually getting the data from a different timezone based on the service provider location rather than the device itself but that was always 1 hour off, DST or not.

    There is an interesting discussion around the setting for the next DST from 2012 that might be what you are hitting. https://social.msdn.microsoft.com/Forums/en-US/9ed8db88-c19f-41d1-9d99-65fd37c7270f/wince6-daylight-saving-time-issue-during-power-off?forum=winembplatdev

    As your setting are volatile I think you are seeing what Paul saw.  Devices with non-volatile registries will never see this issue as the setting would be preserved between updates (Like with Windows Mobile 5.x & 6.x)

    Sincerely,

    IoTGirl 


    Monday, March 27, 2017 5:45 PM
    Moderator
  • Thank you for your reply.  I have tried the HomeDST registry value and it hasn't changed anything.  Looking through the DSTsvc it doesn't even look like it uses this flag.  But knowing WINCE it maybe used somewhere else.  I am seeing if I can play around by enabling/disabling the AutoDST flag but knowing the complexity of the Wince I suspect that I will mess things up.

    I have had a look at discussion from 2012.  They seem to be talking about the same issue I am experiencing.  The recipe they talk about to fix the issue is what I would like to use.  But there is one key piece of information missing.  Half way through the discussion  "Windows CE stores the DST flag, whether we are currently observing summer time or not, in the registry. As I recall, the key name is "DST".

    I have looked through the registry and can't find this DST transition flag.  Does anyone know where key is stored?

    Best regards

    Andrew


    Andrew Meek

    Monday, March 27, 2017 8:00 PM
  • Andrew,

    Sorry, I don't have notes revealing the right answer. Here's what I'd do, however:

    1. Export HKLM and HKCU to your PC using remote registry editor. This is your baseline.

    2. Using a quick bit of C code running on the target, change the DST flag's setting. To do that, you'd call GetTimeZoneInformation() passing a suitable structure pointer and saving the return value. You should receive either TIME_ZONE_ID_STANDARD, or TIME_ZONE_ID_DAYLIGHT from the call. We'll reverse that below.

    3. Enhance your C code using the return value from GetTimeZoneInformation() and calling SetDaylightTime(). If TIME_ZONE_ID_STANDARD was received, pass "1" to SetDaylightTime(); if TIME_ZONE_ID_DAYLIGHT was received, pass "0" to SetDaylightTime(). We're inverting the daylight flag.

    4. Export the same registry branches above to your PC. You'll difference before and after to figure out where in the registry the current daylight flag is stored, if at all.

    Best I can remember, the flag was stored under HKLM/Services/TimeSvc, but that was a while back!

    Paul T.

    • Marked as answer by Andrew Meek Friday, March 31, 2017 3:42 AM
    Monday, March 27, 2017 10:07 PM
  • I can't exactly remember what this was for, but I seem to remember we had a similar problem and this fixed it. If you need more info I can go back and see what our version control system says about this registry key:

    ; To make timezones work properly we enable the default timezone info
    [HKEY_LOCAL_MACHINE\init\BootVars]
        "KTzBias"=hex:01,00,00,00,E0,01,00,00,A4,01,00,00

    Add that to your platform.reg file and see if it makes the issue go away. Otherwise follow Paul's advice.


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: https://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    NXP Proven Partner
    https://guruce.com
    Consultancy, training and development services.

    Interested in WEC on i.MX6?
    Get the only 100% stable and best performing i.MX6 BSP for WEC7 and WEC2013 here: https://guruce.com/imx6

    • Marked as answer by Andrew Meek Friday, March 31, 2017 3:42 AM
    Tuesday, March 28, 2017 7:35 PM
    Moderator
  • Thanks you guys/girls for your help,  you have all helped me put the puzzle together.

    I did find the KTzBias key in the registry.  However this key is read in by the OS at a very early stage in the boot sequence and was virtually impossible to intercept and correct it before it is used by the OS.  As the code that uses the KTzBias is inside the private part of the Wince OS I was unable to go down this path.

    The solution I used to fix (work around) the problem was:

    1) I created a registry key that its default value was '0'.  By modifying the platform.reg file.

    2) If this key was ever set 0 then in is an indication that I have lost my registry (typically caused by wince firmware updates). 

    3) If this registry key is set to 1.  I take a snap shot of the time before the DST service has had time to change it.  After the DST service sent the time ahead, I write to the real time clock what the snap shot is. 

    4) After the real time clock has been set back to it correct value, I then set write a one to my registry key, so further real DST time changes are not affected

    Worst case I lose about 2 seconds of RTC time when I write back the old time.  In my application this is acceptable.

    I can see that there are potential issues if I lose the registry during the DST hours of transitions however I think this is part of the Wince method of implantation and we just have to be aware of.

    Regards,

    Andrew Meek


    Andrew Meek

    Friday, March 31, 2017 3:42 AM