none
Time zone UTC conversion issue in WCE7 RRS feed

  • Question

  • Hi all,
    I am working in WEC700 Platform.

    I am facing problem while changing timezone on our WEC700 iMX6 board.

    once the device gets booted up, timezone properties is opened by clicking taskbar and change timezone.In default cases,timezone will be in pacific time(UTC - 08:00) timezone.


    While i'm trying to change the timezone, UTC Conversions are not proper i.e,if i am changing pacific timezone (UTC - 08:00) to Chennai (UTC + 05:30), the conversion calculation such as UTC - 08:00
    which represent pacific time and UTC + 05:30 which represent chennai time is not updated with proper values as per calculation given(UTC + 05:30),Instead it is updated with improper values.

    In order to track this issue, i tried focussing on source code for timezone.i found timezone.reg file in following path:

    In timezone.reg,they have used timezone.dll,but i couldn't able to find source code of it. 
     
    Is there a solution or way for solving this issue and also where to find timezone.dll source code? 


    Thanks in advance.
    Monday, March 16, 2015 10:23 AM

All replies

  • Say more about "improper values" and we may be able to help. The clock keeps *local time* in Windows CE, so maybe that's the source of your issues. If you change time zones, the local time isn't updated but, because the time zone offset has changed, LocalTimeToSystemTime() results will change. There is certainly a potential for conversion bugs, also, especially for time zones with fractional hour offsets like Chennai.

    Paul T.

    Monday, March 16, 2015 6:50 PM
  • Hi Paul,

    Thanks for your reply.

    I have tested the below mentioned timezones by changing it in imx6 platform without powering off.

    Test cases and updated time is mentioned below:

    Pacific Time(UTC - 08:00) - 12:02PM JAN 1
    casablanca(UTC) - 4:03AM JAN 2
    cairo(UTC + 2:00) - 8:06AM JAN 2
    abu dhabi(UTC + 4:00) - 11:07AM JAN 2
    Dhaka(UTC + 6:00) - 3:08PM JAN 2
    Perth(UTC + 8:00) - 7:09PM JAN 2
    Samoa(UTC + 13:00) - 11:10 PM JAN 1
    Perth(UTC + 8:00) - 6:15PM JAN 2
    Dhaka(UTC + 6:00) - 12:15PM JAN 22
    abu dhabi(UTC + 4:00) - 8:16AM JAN 22
    cairo(UTC + 2:00) - 4:17AM JAN 22
    casablanca(UTC) - 12:18AM JAN 22
    Pacific Time(UTC - 08:00) - 8:19 AM JAN 21


    here, i am denoting improper values which means updated timezone time and date is not as per UTC parameter Which they have mentioned beside time zone within brackets.



    Also this behaviour is inconsistent while test cases are reversed and tested as done above.

    Sindhu
    Thursday, March 19, 2015 5:54 AM
  • So this looks to me like a problem with the clock hardware interface layer for your specific device BSP. I've done this type of time zone changing in various Windows CE versions and although the adjustments were not always what I wanted they always made sense. I've never tested the :30 time zones, but I've checked many adjustments both east and west of UTC.

    What time-keeping method are you using? Are you using the software clock from CE or using OEMGetRealTime() and some type of RTC chip or processor capability? If the latter, I'm betting there's a bug in that code (maybe you're doing OEMGetRealTime correctly but OEMSetRealTime incorrectly or vice versa).

    Paul T.

    Thursday, March 26, 2015 4:52 PM
  • As per your suggestion, I added prints in OEMSetRealTime() and OEMGetRealTime() Which is called 
    by kernel .here OEMGetRealTime() is called continously for every second to update time to OS
    and print is as follows:

    observation 1:

    PID:06540053 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:5.000)
    PID:06540053 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:6.000)
    PID:01BB001E TID:05E20006 -OEMGetRealTime( 2006/1/1 12:13:6.000)
    PID:06540053 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:7.000)
    PID:0442006A TID:04AE0092 -OEMGetRealTime( 2006/1/1 12:13:7.000)
    PID:06540053 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:8.000)
    PID:04D8001F TID:040000DE -OEMGetRealTime( 2006/1/1 12:13:8.000)
    PID:04D8001F TID:040000DE -OEMGetRealTime( 2006/1/1 12:13:8.000)
    PID:06540055 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:9.000)
    PID:06540054 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:10.000)
    PID:06540053 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:11.000)
    PID:06540054 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:12.000)
    PID:06540054 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:13.000)
    PID:06540055 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:14.000)
    PID:06540053 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:15.000)
    PID:06540053 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:16.000)
    PID:06540053 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:17.000)
    PID:00400002 TID:029C0006 -OEMGetRealTime( 2006/1/1 12:13:17.000)
    PID:06540053 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:18.000)
    PID:06540053 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:19.000)
    PID:06540053 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:20.000)
    PID:06540055 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:21.000)
    PID:06540054 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:22.000)
    PID:06540053 TID:072C004A -OEMGetRealTime( 2006/1/1 12:13:23.000)

    OEMSetRealTime() is repeatedly called more than once when apply button is clicked after changing time zone.
    Once the board is powered on, Pacific Time(UTC - 08:00) - 12:13 PM JAN 1 comes as a default time.
    here , if pacific (UTC - 08:00) is converted into Arizona(UTC - 07:00).Time should be changed as 13:17 from 12:17( Initially,time is set properly while changing timezone, but it get changed once same function is called again from kernel which can be noted from below bolded prints).Due to more calls to function OEMSetRealTime(), it changes from 13:17 to 14:17 as follows.


    observation 2:

    ID:0442006A TID:04AE0092 -OEMGetRealTime( 2006/1/1 12:16:58.000)
    PID:06540054 TID:072C004A -OEMGetRealTime( 2006/1/1 12:16:59.000)
    PID:04D80020 TID:040000DE -OEMGetRealTime( 2006/1/1 12:16:59.000)
    PID:06540054 TID:072C004A -OEMGetRealTime( 2006/1/1 12:17:0.000)
    PID:0442006A TID:056C010A -OEMGetRealTime( 2006/1/1 12:17:0.000)
    PID:06540055 TID:072C004A -OEMGetRealTime( 2006/1/1 12:17:0.000)
    PID:06540055 TID:072C004A OEMSetRealTime+++++
    PID:06540055 TID:072C004A +OEMSetRealTime(wYear/mnth/day: 2006/1/1
                                                                       hour:min:sec:millisec: 13:17:0.000
    PID:06540055 TID:072C004A OEMSetRealTime-----
    PID:06540055 TID:072C004A -OEMGetRealTime( 2006/1/1 13:17:0.000)
    PID:06540055 TID:072C004A -OEMGetRealTime( 2006/1/1 13:17:0.000)
    PID:06540055 TID:072C004A OEMSetAlarmTime++++++
    PID:06540055 TID:072C004A OEMSetAlarmTime-----
    PID:0442006A TID:056C010A -OEMGetRealTime( 2006/1/1 13:17:0.000)
    PID:00400004 TID:072C004A -OEMGetRealTime( 2006/1/1 13:17:0.000)
    PID:00400004 TID:072C004A OEMSetRealTime+++++
    PID:00400003 TID:072C004A +OEMSetRealTime(wYear/mnth/day: 2006/1/1
                                                                       hour:min:sec:millisec: 14:17:0.000
    PID:00400003 TID:072C004A OEMSetRealTime-----
    PID:01BB0021 TID:01D0003E -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400003 TID:056C010A -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400002 TID:07B40002 -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:01BB001F TID:01CB004A -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400002 TID:070B00BE -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:01BB0020 TID:01CB004A -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400005 TID:070B00BE -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:01BB001F TID:01CB004A OEMSetAlarmTime++++++
    PID:01BB001F TID:01CB004A OEMSetAlarmTime-----
    PID:04D80020 TID:040000DE -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:01BB001F TID:01CB004A -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400002 TID:070B00BE -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:01BB0020 TID:01CB004A -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:01BB0020 TID:01CB004A OEMSetAlarmTime++++++
    PID:01BB0020 TID:01CB004A OEMSetAlarmTime-----
    PID:00400002 TID:07B40002 -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400005 TID:07B40002 -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400003 TID:07B40002 -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400003 TID:07B40002 -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:0442006A TID:06950002 -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:0442006B TID:056C010A -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400005 TID:070B00BE -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:04D80020 TID:040000DE -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400005 TID:07B40002 -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400005 TID:07B40002 -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400005 TID:07B40002 -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400004 TID:07B40002 -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400004 TID:07B40002 -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400005 TID:056C010A -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:04D80020 TID:040000DE -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:01BB001F TID:01CB004A -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400004 TID:072C004A -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400004 TID:072C004A OEMSetRealTime+++++
    PID:00400004 TID:072C004A +OEMSetRealTime(wYear/mnth/day: 2006/1/1
                                                                       hour:min:sec:millisec: 14:17:0.000
    PID:00400004 TID:072C004A OEMSetRealTime-----
    PID:01BB0021 TID:01CB004A -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:01BB0021 TID:01CB004A OEMSetAlarmTime++++++
    PID:01BB0021 TID:01CB004A OEMSetAlarmTime-----
    PID:00400004 TID:070B00BE -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:0442006B TID:056C010A -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:070800C0 TID:070B00BE -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400002 TID:056C010A -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400005 TID:070B00BE -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:01BB0020 TID:01CB004A -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:06540053 TID:072C004A -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:01BB0020 TID:01CB004A -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:01BB0020 TID:01CB004A OEMSetAlarmTime++++++
    PID:01BB0020 TID:01CB004A OEMSetAlarmTime-----
    PID:00400002 TID:070B00BE -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:06540054 TID:072C004A -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400005 TID:070B00BE -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400005 TID:070B00BE -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400005 TID:070B00BE -OEMGetRealTime( 2006/1/1 14:17:0.000)
    PID:00400005 TID:070B00BE -OEMGetRealTime( 2006/1/1 14:17:0.000)


    Function calls(OEMSetRealTime) from kernel is also not constant i.e, No of call to function OEMSetRealTime() varies.
    Saturday, April 11, 2015 10:37 AM
  • I think that this is a long standing problem with changing the date/time that is related to the automatic adjust clock for daylight saving.

    We all would expect that when selecting Ok or Apply that the time that we set take affect, but instead it seems to set the time and then factor in the daylight savings.   So when changing the check mark for DST or changing the date into/out of DST then the time gets changed incorrectly.


    Bruce Eitman (eMVP) Senior Engineer Bruce.Eitman AT Eurotech DOT com My BLOG http://geekswithblogs.net/bruceeitman Eurotech Inc. www.Eurotech.com

    Monday, April 13, 2015 1:05 PM
    Moderator
  • Yes, that can definitely happen. Please also remember that Arizona may not be the time zone you want to compare, as we DO NOT OBSERVE DAYLIGHT SAVING TIME...ever. So, depending on the current time (winter or summer), changing the time zone between Pacific and Arizona may or may not want to change the clock (yes in winter, no in summer).

    This is related to the DST flag which the system calculates at various poorly-chosen times and doesn't really maintain through reboots. It figures out, for the currently-selected time zone, and the date/time you just set, should DST flag be set based on time zone parameters. If it was not set and now is, the DST adjustment is also applied.

    My own devices tried much harder to keep track of whether the current date/time is based on DST=yes or DST=no so that time conversions are somewhat more predictable. They used battery-backed clock chips so you can store the DST transition date/time and the DST flag in a place where they will be recoverable after a reboot.

    I think it's safe to assume that you can't fix the time zone conversions *during time zone change*. So, what can be done? You can set the default time zone to a more-appropriate one for your customers. You can cause the startup code in the time service to set the DST flag on startup (based on 1/1/2000 or whatever the default clock and time zone settings are). Say more about the main concern you have; maybe we can identify some improvements.

    Paul T.

    Tuesday, April 28, 2015 9:02 PM