by Michael S. Kaplan, published on 2011/01/03, original URI: http://blogs.msdn.com/b/michkap/archive/2011/01/03/10110996.aspx
The question that came up was pretty clear:
Get-Date cmdlet in powershell does not reflect the changes done in TimeZone setting. New changes are reflected only after I open a new powershell window.
1. Open a PowerShell window
2. execute get-date [current time is shown]
3. change timezone settings to different timezone.
4. execute get-date [new time zone changes are not reflected]
5. Open another PowerShell window, execute get-date [new timezone changes are reflected]
Is this a BUG or by design?
I checked that cmd.exe reflects the change in TimeZone settings on the same window and expect powershell to behave no differently.
One might be thinking about my So what happened in v.Next? that explained how in .NET >= 1.1 there is a way to properly automate getting updates to locale data and calling ClearCachedData, described in How ClearCachedData found its way into the .NET Framework.
And the reason I was reminded? Because we are talking about the same bug, with the same solution, really!
In regard to time zone stuff, this is even covered in a Connect bug report: DateTime.Now does not appear to recognize timezone changes. The documentation must reflect this.
Now there may or may not be notifications that work in this scenario, even though functions that change time zone info like SetTimeZoneInformation specifically recommend broadcasting a WM_SETTINGCHANGE message. Because you may not have a way to get messages when in a PowerShell command line script. And not everyone sends that message....
However, you can always call ClearCachedData before making the get-date call if you are worried about the scenario.
If you ask me, it should be an optional parameter for things like get-date to do this for you, but I'm not going to quibble....
go to newer or older post, or back to index or month or day