We are using the win32_NTLogEvent class to retrieve events and store them to
a database. We have noticed that in windows 2008 32bit and vista 32bit the
win32_NTLogEvent.TimeGenerated is returned in GMT with an offset value of
000. In earlier versions of windows, win32_NTLogEvent.TimeGenerated is
returned in localtime with an offset relative to GMT.
For Example these two are exactly the same date:
WinXP TimeGenerated 10:00 GMT 120 (20091016100000.000000+120)
Vista/2008 TimeGenerated 08:00 GMT 000 (20091016080000.000000+000)
This, of course, creates inconsistency in data depending on the source OS.
We would like to know if this change is intentionate and if means of easily
recovering the local time instead have been provided.
Thank you very much,
Tango.
> This, of course, creates inconsistency in data depending on the source
> OS. We would like to know if this change is intentionate and if means
> of easily recovering the local time instead have been provided.
Why not just have your code convert GMT values to local time whenever the offset is 0? Look at SystemTimeToFileTime(), FileTimeToLocalFileTime(), and other related functions.
--
Remy Lebeau (TeamB)
The problem is that we are retrieving remote data using WMI, we need to get
the local time for the eventlog message in the REMOTE computer, and I think
using the API we will bet the date in the local computer where we are
executing the WMI query.
For Example in a remote WinXP when we retrieve the EventLog message with
TimeGenerated 10:00 GMT 120 (20091016100000.000000+120) we know there was
10:00 in the remote computer clock but when retrieving the same EventLog
message from a remote Vista/2008, the TimeGenerated will be 08:00 GMT 000
(20091016080000.000000+000) so we can't get the "real remote time" where the
message was generated.