Dealing with time zones is a major pain in the @$$. One thing to consider is that Windows only stores the current DST rules, not historic rules. So if you are relying on the rules to be able to accurately recreate the old values, you might find some discrepancies in your data. DST rules change all the time. Some countries don't even have set rules, they just announce the dates every year.
If you cannot afford discrepancies in your data, you might be better off storing the date as a string with the time zone information encoded in it. In .Net you can use DateTime.ToString("O"). This format is culture agnostic so you will always get the same format no matter what culture the code is running in.
var origDt = DateTime.Now;
var dtStr = origDt.ToString("O");
var newDt = DateTime.Parse(dtStr, null, System.Globalization.DateTimeStyles.RoundtripKind);
Console.WriteLine(dtStr);
if (newDt == origDt)
Console.WriteLine("Dates equal"); // should be true
else
Console.WriteLine("Dates not equal");
Check out the MSDN documentation for more information on this format style.
Of course this comes at a cost. It will be inefficient to search the database by date (it can be done, but the strings need to be converted to dates). Chances are the time zone differences won't matter too much anyway. It really depends on what you are doing with the data and how important accuracy is.
You might want to make sure that the project actually requires UTC and time zones before you go down this path. There is a decent chance that just storing the time from the local computer and ignoring time zones is good enough.