DateTime property values off of objects returned from the Operations Manager (OM) SDK are in UTC time. At the time of this writing the "Kind" property of these values is not populated. This may seem trivial or irrelevant but it raises some questions as to how Cmdlets designed to take DateTime values should treat values that do not specify the "Kind" property. Consider the following example.
Monitoring:\localhost\Microsoft.SystemCenter.AllComputersGroup>$time = [DateTime]::Now >$timeMonday, November 27, 2006 6:35:10 PM >$time.KindLocal >New-MaintenanceWindow -startTime: ($time) -endTime: ($time.AddDays(1)) -reason: "ApplicationInstallation" -comment: "Testing DateTime.Now"; >Monitoring:localhost\>Get-MaintenanceWindow MonitoringObjectId : 3c8ac4f3-475e-44dd-4163-8a97af363705 StartTime : 11/28/2006 2:35:12 AMScheduledEndTime : 11/29/2006 2:35:12 AMEndTime Reason : ApplicationInstallationComments : testing DateTime.NowUser : SMX\asttestLastModified : 11/28/2006 2:35:12 AMManagementGroup : rogers01dmgManagementGroupId : 4e2f3ced-4b50-3939-edac-b9dfabe5effa
Monitoring:\localhost\Microsoft.SystemCenter.AllComputersGroup>$time = [DateTime]::Now
>$timeMonday, November 27, 2006 6:35:10 PM
>$time.KindLocal
>New-MaintenanceWindow -startTime: ($time) -endTime: ($time.AddDays(1)) -reason: "ApplicationInstallation" -comment: "Testing DateTime.Now";
>Monitoring:localhost\>Get-MaintenanceWindow MonitoringObjectId : 3c8ac4f3-475e-44dd-4163-8a97af363705
StartTime : 11/28/2006 2:35:12 AMScheduledEndTime : 11/29/2006 2:35:12 AMEndTime Reason : ApplicationInstallationComments : testing DateTime.NowUser : SMX\asttestLastModified : 11/28/2006 2:35:12 AMManagementGroup : rogers01dmgManagementGroupId : 4e2f3ced-4b50-3939-edac-b9dfabe5effa
Clearly some conversion has occurred here. The value from [DateTime]::Now is in local time. The New-MaintenanceWindow Cmdlet converts the local time to UTC time before creating the maintenance window. All is good as the maintenance window will occur at the local time specified by the user. If you try the same example by specifying a string value for the DateTime parameters you get a different result. Consider the following example where the user is working in the PST time zone.
>[DateTime] $time = "11/28/2006">$timeMonday, November 28, 2006 12:00:00 AM>$time.KindUnspecified >New-MaintenanceWindow -startTime: $time -endTime: ($time.AddDays(1)) -reason: "ApplicationInstallation" -comment: "Testing DateTime string conversion"; >Monitoring:localhost\>Get-MaintenanceWindowMonitoringObjectId : 3c8ac4f3-475e-44dd-4163-8a97af363705StartTime : 11/28/2006 12:00:00 AMScheduledEndTime : 11/29/2006 12:00:00 AMEndTime :Reason : ApplicationInstallationComments : testing DateTime.NowUser : SMX\asttestLastModified : 11/28/2006 2:40:00 AMManagementGroup : rogers01dmgManagementGroupId : 4e2f3ced-4b50-3939-edac-b9dfabe5effa
>[DateTime] $time = "11/28/2006">$timeMonday, November 28, 2006 12:00:00 AM>$time.KindUnspecified
>New-MaintenanceWindow -startTime: $time -endTime: ($time.AddDays(1)) -reason: "ApplicationInstallation" -comment: "Testing DateTime string conversion"; >Monitoring:localhost\>Get-MaintenanceWindowMonitoringObjectId : 3c8ac4f3-475e-44dd-4163-8a97af363705StartTime : 11/28/2006 12:00:00 AMScheduledEndTime : 11/29/2006 12:00:00 AMEndTime :Reason : ApplicationInstallationComments : testing DateTime.NowUser : SMX\asttestLastModified : 11/28/2006 2:40:00 AMManagementGroup : rogers01dmgManagementGroupId : 4e2f3ced-4b50-3939-edac-b9dfabe5effa
Great, the time value specified is the time value that is returned. All is good, or so it seems. There is a problem. The time is understood to be UTC time to the server that determines when the maintenance window starts and stops. In this case the maintenance window is going to start on 11/27/2006 at 2 PM PST. This is not what the user intended in this case. This same problem also occurs when using a DateTime value off of an SDK object to specify the parameter of type DateTime on the OM Cmdlets. If you are confused, try to remember the following guidelines.