Date/Time picker is not passing the correct time to Orchestrator

Adam_Morris

I'm testing a Request Offering that uses the Date/Time picker. When I select 5PM or later, the time that is sent to Orchestrator is off by 6 hours.

For example: If I select 4PM, the time that is passed to Orchestrator is 4PM. However, if I select 5PM, Orchestrator sees 11PM.

If I open the Service Request, it shows the time I actually selected. Does anyone know why Orchestrator would be getting an incorrect time?

Tom_Hendricks

I might, especially if you are still using 2012 R2.  I reported a bug to Microsoft last year about the SCSM IP not accepting negative numbers for object properties, which is problematic for things like time zone offsets if you are in the Americas.  This sounds like it could be related.

I believe that this was fixed in 2016, but I have not tested it since I had to abandon my entire approach months before 2016 came out.  It was not fixed in any of the 2012 R2 UR's.

Adam_Morris

Brian, I ended up using the following powershell script to adjust the time. Using this method, you don't have to make any manual adjustments when daylight savings time starts or ends.

$Time = "{DateTime from "Initialize Data"}"

$strCurrentTimeZone = (Get-WmiObject win32_timezone).StandardName
$TZ = [System.TimeZoneInfo]::FindSystemTimeZoneById($strCurrentTimeZone)
$Time = [System.TimeZoneInfo]::ConvertTimeFromUtc($Time, $TZ)

Tom_Hendricks

I might, especially if you are still using 2012 R2.  I reported a bug to Microsoft last year about the SCSM IP not accepting negative numbers for object properties, which is problematic for things like time zone offsets if you are in the Americas.  This sounds like it could be related.

I believe that this was fixed in 2016, but I have not tested it since I had to abandon my entire approach months before 2016 came out.  It was not fixed in any of the 2012 R2 UR's.

Adam_Morris

Yep, we are using 2012 R2 and I am in the central time zone (-06:00) so I guess that explains the 6 hour time difference.

We were already planning on upgrading to 2016 this weekend. I'll test it after the upgrade and post the results.

Thanks for the info.

Brian_Wiest

This effect us as well. 
When users complete the work item form either by portal or console the date time is captured by local time zone. 
Then it is stored in the SQL database as UTC time yyyy-MM-ddThh:mm:ss.
When your run book pulls the value from the work item it does so as UTC and when adding to SharePoint on the local time of the servers. (For me all servers are EST) 
So in our runbook we have a Format Date/Time control that adjusts for time zone so the data gets posted to SharePoint in the proper format. Including a modifier of -5 hours (which we have to manual update when daylight savings starts/ends)

Adam_Morris

I've updated everything to 2016 and the issue still exists.

Tom_Hendricks

That is unfortunate.  I cannot locate it at the moment, but I thought it was mentioned in the 2016 release notes.  I recommend raising another ticket with Microsoft and/or just handling this step with PowerShell (which was the workaround they provided before closing my ticket).

Adam_Morris

Brian, I ended up using the following powershell script to adjust the time. Using this method, you don't have to make any manual adjustments when daylight savings time starts or ends.

$Time = "{DateTime from "Initialize Data"}"

$strCurrentTimeZone = (Get-WmiObject win32_timezone).StandardName
$TZ = [System.TimeZoneInfo]::FindSystemTimeZoneById($strCurrentTimeZone)
$Time = [System.TimeZoneInfo]::ConvertTimeFromUtc($Time, $TZ)

Brian_Wiest

To Share
Updated the script to pull two time values.

$SSTime = "{Scheduled start date from "Get Service Request"}"

$SETime = "{Scheduled end date from "Get Service Request"}"

$strCurrentTimeZone = (Get-WmiObject win32_timezone).StandardName

$TZ = [System.TimeZoneInfo]::FindSystemTimeZoneById($strCurrentTimeZone)

$StartTime = [System.TimeZoneInfo]::ConvertTimeFromUtc($SSTime, $TZ)

$EndTime = [System.TimeZoneInfo]::ConvertTimeFromUtc($SETime, $TZ)

And added two entries to published data.


Works like a charm.