Comments and suggestions needed...

Thank you for the resource I think it looks great.

By the way
Bit nicely put.

For example, while USB thumb drives appear in the System file, I've found a way to tie the use of such things to a specific user…but this isn't something that fits nicely and neatly into a small reference guide.

H

Hi Harlan,

I was interested in your comment quoted. I am currently needing to prove exactly this. In fact, your book is due to arrive with me having been ordered a few days back - is this solution included in your book? If yes, great. If not, are you able to share it with me?

Thanks.

Dan.

Locating the USB thumb drives in the System file is something that's been covered here as well as in my book. I've been able to tie a USB-connected external HDD to a specific user via the NTUSER.DAT file. Tying a thumb drive to a specific user is a bit more involved, and requires mapping the thumb drive to the drive letter it was mounted as, and then via Windows shortcut files…

Locating the USB thumb drives in the System file is something that's been covered here as well as in my book. I've been able to tie a USB-connected external HDD to a specific user via the NTUSER.DAT file. Tying a thumb drive to a specific user is a bit more involved, and requires mapping the thumb drive to the drive letter it was mounted as, and then via Windows shortcut files…

Look at Harlan trying to get his post count up lol

Well, duplicates or not, at least I'm posting content… 😉

Thank you all for your wonderful feedback. I almost have a second revision of this quick reference completed.

I assume Azrael means keys such as
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation

Indeed, also http//support.microsoft.com/kb/115231 …

-)

One question,
Would this registry key only be useful in determining the current time zone? Is there a way to determine the ACTUAL system time in the registry or is that not a defined in the registry.. I know we get the time from a setting in the registry that points to microsoft's time server (time.microsoft.com), but I guess I'm wondering if there is anything else in the TimeZoneInformation key other than EST, PST, etc.

What if the timezoneinformation says EST, but the system clock is actually off by 2 hours? Is there anywhere in the registry that would determine that?

Is there any significance to these values in the TimeZoneInformation key

ActiveTimeBias
Bias
DaylightBias
DaylightName (obvious)
DaylightStart
StandardBias
StandardName (obvious)
StandardStart

I am aware of the significance of the two values I put "(obvious)" next to, but what about the others? What do those hex values mean?

Thanks,
Derrick

Derrick,

To answer your questions…

First, I don't know of any Registry entry that records the actual system time itself. There are a lot of entries that record the timestamps (ie, FILETIME object) of various events, but none that I'm aware of the record the system time.

As to your question about the info in the TZI key, while the two values you marked as "obvious" may be…well…obvious as to their meaning, they are simply string values that are not processed in any way by the OS. Yes, they are _read_ and printed in the GUIs, but they are not actually used for any processing purposes; this means that they can be anything and not affect the overall function of the system.

ActiveTimeBias is the important one if the system has daylight savings setttings set. This gives you the value of the offset from UTC/GMT time in minutes, but from a Unix time perspective. What this means is that you can translate the 64-bit FILETIME object into a 32-bit Unix t_time value, and then subtract (if you're within CONUS) the number of minutes in the ActiveTimeBias from the UTC time to get the actual time (within the time zone) that the event occurred.

HTH

ActiveTimeBias is the important one if the system has daylight savings setttings set. This gives you the value of the offset from UTC/GMT time in minutes, but from a Unix time perspective. What this means is that you can translate the 64-bit FILETIME object into a 32-bit Unix t_time value, and then subtract (if you're within CONUS) the number of minutes in the ActiveTimeBias from the UTC time to get the actual time (within the time zone) that the event occurred.

HTH

Let me see if I understand this…

The last 8 bytes or 64 bits of a registry key data value is the FILETIME object and when converted from hex to decimal this is the number of nanoseconds since January 1, 1601..

When that number is broken down and translated it becomes the GMT time stamp. Then in order to convert GMT to a specific timezone you would subtract the amount of minutes from ActiveTimeBias to get the actual time. For example, Easter Standard Time is -240 minutes or -5 hours.

How come though when I change my system time to be ahead 2 hours the ActiveTimeBias value doesn't change? Shouldn't it change to reflect exactly how many minutes difference there are between timezone and GMT? And if it doesn't change, how would this be accurate in reflecting the exact time an event occurred?

I'm not sure if I'm overcomplicating this and I apologize if I am, but I'm trying to write about it and explaining it in words is quite challenging, especially when I'm not quite sure if I'm getting it completely correct myself.

Thank you Harlan,
Derrick

ActiveTimeBias is the important one if the system has daylight savings setttings set. This gives you the value of the offset from UTC/GMT time in minutes, but from a Unix time perspective. What this means is that you can translate the 64-bit FILETIME object into a 32-bit Unix t_time value, and then subtract (if you're within CONUS) the number of minutes in the ActiveTimeBias from the UTC time to get the actual time (within the time zone) that the event occurred.

HTH

Let me see if I understand this…

The last 8 bytes or 64 bits of a registry key data value is the FILETIME object and when converted from hex to decimal this is the number of nanoseconds since January 1, 1601..

Hhhhmm….don't know where you got that, as that wasn't what I said.

First off, what exactly is "a registry key data value"?? 😉

More specifically, *some* Registry value data does, in fact, contain 8 bytes that comprise a FILETIME object, just as you describe. This does not mean that it's always the case, however.

When that number is broken down and translated it becomes the GMT time stamp. Then in order to convert GMT to a specific timezone you would subtract the amount of minutes from ActiveTimeBias to get the actual time. For example, Easter Standard Time is -240 minutes or -5 hours.

That's a good approximation, sure.

How come though when I change my system time to be ahead 2 hours the ActiveTimeBias value doesn't change?

Because you've changed the system time, and done nothing to modify the Time Zone Information or the ActiveTimeBias, specifically.

Shouldn't it change to reflect exactly how many minutes difference there are between timezone and GMT?

Yes, it should…but again, you've changed the system time. You *haven't* done anything to change the timezone or GMT.

And if it doesn't change, how would this be accurate in reflecting the exact time an event occurred?

I hope by now, you've seen the answer. 😉

I'm not sure if I'm overcomplicating this and I apologize if I am, but I'm trying to write about it and explaining it in words is quite challenging, especially when I'm not quite sure if I'm getting it completely correct myself.

Not overcomplicating so much as simply taking it in the wrong direction. Remember, I said previously that to the best of my knowledge, there are no Registry keys that maintain the system time. What you've done is actually illustrated my point for me…that modifications to the system time have no impact on the time zone information. 😉