The ConvertToDateTime() ScriptMethod is incorrect / broken and does NOT take into account the current time zone as defined by System.Management.ManagementDateTimeConverter.ToDateTime() method. In fact, it's not applying any time zone at all. Full analysis and test scripts at my blog - https://goo.gl/b4ZTqf
M.Pahulje, MVP commented
Hi Ilya, thank you and you are correct, in your assumption of not restarting Powershell (PS). (koodoos)
However, there is an error still occuring.
When you run the PS code line 1, (Get-WmiObject Win32_OperatingSystem).InstallDate it emits CIM_DATE 20100216060920.000000-300 for me in my default Eastern Time Zone. Then while PS is still running, I change the time zone to UTC, rerun line 1 and get CIM_DATE 20100216060920.000000+000 which indicates it correctly grabbed new change time zone to UTC (indicated by +000). Time zone offset being indicate by +/-*** in minutes in CIM_DATE format.
The InstallDate in UTC time zone remains the same, if you restart PS or not. This tells us PS is grabbing the correct changed time zone, while PS is still running. So far, so good, behaviour as expected.
But the next PS code line 2, ([WMI]'').ConvertToDateTime((Get-WmiObject Win32_OperatingSystem).InstallDate) does not apply the change time zone to UTC (while still running PS) as you keenly indicated. (great catch btw!). Only when you reboot PS code line 2 gives you the correct result and applies the change time zone. This is the error.
So I vote this still a PS issue, since the line 1 is saying it pick-up the time zone change, but does not apply it to line 2 calculation. Conversely, if PS did not pick-up time zone change in line 1, then you would think to restart PS so it might get the new time zone.
Ilya Sazonov commented
It is not PowerShell issue, it is .Net Framework issue.
I guess that after changing timezone you re-run C# exe but not re-run PowerShell.