Re: CE 5.0, TIMESVC fails to set clock back to correct time
- From: "John Spaith [MS]" <jspaith@xxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 5 Jan 2006 14:23:47 -0800
It turns out that this is a protocol limitation. From
http://www.faqs.org/rfcs/rfc1361.html
<
Note that since some time in 1968 the most significant bit (bit 0 of
the integer part) has been set and that the 64-bit field will
overflow some time in 2036. Should NTP or SNTP be in use in 2036,
some external means will be necessary to qualify time relative to
1900 and time relative to 2036 (and other multiples of 136 years).
>
I verified that a CE device set to 2035 works just fine, but 2037 ends up
getting confused. I'm not going to worry about this quite yet. Western
Civilization will probably end anyway with the UnixTime overflow on Jan 19
2038 (my 61st birthday btw) shortly after 2036 anyway :).
I will open up a documentation bug so that people know to get their clocks
set to something reasonable when using SNTP.
--
John Spaith
Software Design Engineer, Windows CE
Microsoft Corporation
Check out the new CE Networking Team Blog at http://blogs.msdn.com/cenet/.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. © 2003 Microsoft Corporation. All rights
reserved.
"John Spaith [MS]" <jspaith@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:OsQDDY0$FHA.2320@xxxxxxxxxxxxxxxxxxxxxxx
> Also be aware this may be some sort of protol limitation, as in the clock
> has to be in the general vicinity of being correct, so there may not be
> anything we can do. I don't have time at the present to dig into this
> further but will.
>
> --
> John Spaith
> Software Design Engineer, Windows CE
> Microsoft Corporation
>
> Check out the new CE Networking Team Blog at http://blogs.msdn.com/cenet/.
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> You assume all risk for your use. © 2003 Microsoft Corporation. All rights
> reserved.
>
> "John Spaith [MS]" <jspaith@xxxxxxxxxxxxxxxxxxxx> wrote in message
> news:uAXEgU0$FHA.3992@xxxxxxxxxxxxxxxxxxxxxxx
>>I have followed your repro steps and see the same bug that you do. Our
>>apologies for this problem. The real time clocks on systems that we test
>>with always have their clocks set to sometime in the past on first boot,
>>not this far in the future. Out of curiosity (not that it changes the
>>fact this is a bug), is your system clock this far in the future or did
>>you hit this just via experimentation?
>>
>> Please contact your technical account manager or whoever you contact for
>> support and let them know about this issue if you want a QFE. (I'll open
>> a bug in our product bug database no matter what.) You should not get
>> charged for a support incident when it is a bug in an MS product. You
>> can definitely use my name as someone in MS who has confirmed this issue.
>>
>> --
>> John Spaith
>> Software Design Engineer, Windows CE
>> Microsoft Corporation
>>
>> Check out the new CE Networking Team Blog at
>> http://blogs.msdn.com/cenet/.
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> You assume all risk for your use. © 2003 Microsoft Corporation. All
>> rights reserved.
>>
>> "AJM42" <software@xxxxxxxxxxxxxx> wrote in message
>> news:1134402074.824752.120950@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>A bit more on this.
>>> It is not simply due to unsigned maths as I first thought.
>>> It seems to depend how far the clock is wrong.
>>> For example, if the clock is 2020 then it sets it back to 2005 OK.
>>> I am continuing to investigate - but if anyone welse has any ideas in
>>> mean time?
>>>
>>
>>
>
>
.
- Prev by Date: Re: Graphics Device Interface Test-Polygon failed
- Next by Date: Re: CE image too big for my computer???
- Previous by thread: Re: Hard Drive problem....
- Next by thread: Re: PC Card legacy Miniport NDIS driver doesn't load under CE5.0
- Index(es):
Relevant Pages
|
