Closed mattmcnabb closed 8 years ago
Current plan is to use DateTimeOffset for all date properties and parameters. When used in a filtering parameter, such as the -Since or -Until parameters of Get-OneLoginEvent, these will be converted to strings in UTC and passed to the API.
The only problem with this is that the date properties of objects returned will display in UTC with a +00 offset. This is because the ToString() method of DateTimeOffset uses the UTCDateTime property to get it's value.
There are two solutions to this:
Tested using Add-Member and execution difference is significant:
PS Repos:\OneLogin> $1Event = $events[0]
function New-CustomEvent
{
param ($object)
$Object -as [OneLogin.Event] | Add-Member -MemberType ScriptMethod -Name ToString -Value {$_.LocalDatetime.ToString()} -Force
$Object
}
PS Repos:\onelogin> measure-command {1..100 | % {new-customevent -object $1Event}}
Days : 0
Hours : 0
Minutes : 0
Seconds : 0
Milliseconds : 88
Ticks : 886513
TotalDays : 1.02605671296296E-06
TotalHours : 2.46253611111111E-05
TotalMinutes : 0.00147752166666667
TotalSeconds : 0.0886513
TotalMilliseconds : 88.6513
PS Repos:\onelogin> measure-command {1..100 | % {$1Event -as [Onelogin.Event]}}
Days : 0
Hours : 0
Minutes : 0
Seconds : 0
Milliseconds : 7
Ticks : 76068
TotalDays : 8.80416666666667E-08
TotalHours : 2.113E-06
TotalMinutes : 0.00012678
TotalSeconds : 0.0076068
TotalMilliseconds : 7.6068
Still need to test with custom format calculation to see if there is significant overhead. Initial thoughts are that it will be quicker since the extra time is probably due to Add-Member.
All object datetime properties should display local times, and any calls to the API should convert local time to UTC for accuracy. Can [DateTimeOffset] fulfill this need?