M.Pahulje, MVP

My feedback

  1. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  PowerShell » WMI  ·  Flag idea as inappropriate…  ·  Admin →
    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.

    M.Pahulje, MVP shared this idea  · 

Feedback and Knowledge Base