DateTime conversions

[DazzaManazza]

I understand that the AT API only deals in EST timezones so this is not an issue as such, it would be a great usability feature however if output and input DateTimes could assume the Local Time zone.

I am in London, my Autotask Internal location is set with the GMT time zone as is my PC running powershell

Example Output looking at 1 specific "Time Entry". In the below example the local time when this time entry was posted was "3 August 2018 09:20 am"

Get-AtwsTimeEntry -id 48538

TaskID                         : 
TicketID                       : 39927
InternalAllocationCodeID       : 29682801
Type                           : 2
DateWorked                     : 03/08/2018 00:00:00
StartDateTime                  : 03/08/2018 04:11:00
EndDateTime                    : 03/08/2018 04:20:00
HoursWorked                    : 0.1500
HoursToBill                    : 0.2500
OffsetHours                    : 0.0000
SummaryNotes                   : {REMOVED}
InternalNotes                  : 
RoleID                         : 29683355
CreateDateTime                 : 03/08/2018 04:20:01
ResourceID                     : 29682891
CreatorUserID                  : 29682891
LastModifiedUserID             : 29682891
LastModifiedDateTime           : 03/08/2018 04:20:01
AllocationCodeID               : 29682801
ContractID                     : 29683748
ShowOnInvoice                  : False
NonBillable                    : False
BillingApprovalLevelMostRecent : 0
BillingApprovalResourceID      : 
BillingApprovalDateTime        : 
ContractServiceID              : 
ContractServiceBundleID        : 
Fields                         : 
id                             : 48538
UserDefinedFields              : {}

Looking at the available properties of the StartDateTime field :

$te = Get-AtwsTimeEntry -id 48538
foreach ($t in $te){
$t.startdatetime | format-list
}

Date        : 03/08/2018 00:00:00
Day         : 3
DayOfWeek   : Friday
DayOfYear   : 215
Hour        : 4
Kind        : Unspecified
Millisecond : 0
Minute      : 11
Month       : 8
Second      : 0
Ticks       : 636688662600000000
TimeOfDay   : 04:11:00
Year        : 2018
DateTime    : 03 August 2018 04:11:00

Feeding the response date into

[System.TimeZoneInfo]::ConvertTimeBySystemTimeZoneId($t.StartDateTime, "Eastern Standard Time", [system.timezoneinfo]::Local.Id)

seems to converts fine, so it can be worked around, but there are a lot of fields to remember to convert.

Thanks

Darren

[AlexHeylin]

Agreed, this is a pain point in an otherwise wonderful module! The issue is that currently PowerShell thinks / assumes the DateTimes are in UTC so calling .ToUniversalTime() doesn't change them to UTC.

For my money, either the module should return the DateTimes with the timezone / offset (so you can call .ToUniversalTime()) or if timezone can't be passed, they should be returned in UTC (possibly as separate attributes named with UTC suffix). At first glance adding the offset to the existing DateTime output should be a non-breaking change that should not affect existing uses of this module, but would allow easier time offset correction. When I get bored enough I might have a crack at writing this in and PR it.

@DazzaManazza - thanks for the string above, it's made life a lot easier than the simple maths I was trying to do that would randomly fail badly.

[DazzaManazza]

Hi AlexHeylin, glad the conversion string helped, it was a lucky google find if i'm honest.

I recently realised myself that since version 0.2.2.2 of this module it now converts DateTime values to local time, including the UTC offset. I have striped out my own conversions now and while I have not tested it thoroughly it seems to be working fine.

Interestingly I see that Datto's 2018.3 release due next month introduces the next version of the API, which seems to nail down authentication a lot. Hopefully that's not problematic for this here super module.

[klemmestad]

Hi guys, Yes, I have added DateTime conversion to the module. It was a lot of extra work to handle dates manually when scripting and it seemed like exactly the kind of chore the module ought to handle for you. Currently it separates Dates from DateTime by assuming that a time of 00:00.00.000 (hh:mm.ss.ms) is a date. All other time values are assumed to be full DateTime fields. This has worked fine in our testing, but as we are working against live PSA databases we cannot test as extensively as we probably should. Please let me know if you find any issues!

The new API version is published at a new web service endpoint, so the module will continue to work unchanged as long as API version 1.5 is supported. I will start work on supporting API version 1.6 when our region (London) is upgraded in January.

[klemmestad]

Timezone conversion and datehandling (knowing when a datetime object is a date and not datetime) is updated and integrated in the module. Version 1.6 of the api is fully supported also.