I have one question about the time I get from the function call "NetworkTime.GetLowAccuracyTimeSynch", the time in the return value is the same with the time that I get from the browser http://
Browser's datetime : 2010/1/29 am 10:10
function call's datetime : 2010/1/30 am 10:10
That's odd. Could you tell me what version of AMT you have so I can try to replicate this?
Edit: Also, what you were viewing the time with and what time zone you're in.
First of all, thanks for your response, as your response, The AMTI used is iAMT 6.0, and the time zone is GMT+8 at Taipei.
I use Commander Tool version v0.6.0937.2 and check the engine time use the "Set Time" button in the Tab "Intel Management Engine", the engine time is the same as the description I posted before, it will show one day before the exactly date that I set in the ME.
On my systems, I'm seeing the same behavior with the DTK. When I examined the actual GetLowAccuracyTimeSynchresponse packet with Wireshark, then pulled the value out and converted it myself, the date and time matched that in the WebUI. I think this is a bug with how the commander is reporting back the time, in this case.
The time that's reported is typically set by the SCS (or other configuration server) as part of the configuration process. If you've remotely configured a system, but haven't remotely set the time to UTC time, the time that comes back from the GetLowAccuracyTimeSynch should be the same as the SMBIOS clock. What's in the SMBIOS clock depends on your system and how you configured it. By default, Windows systems set the SMBIOS clock to local time (the BIOS clock should show the same time as your OS), and Linux-based systems set the BIOS clock to UTC time.
I'd recommend using the time you get back with the GetLowAccuracyTimeSynch call as is, instead of going through the calculations the DTK does to adjust the time that is returned from GetLowAccuracyTimeSynch.