[Beta feature] Added option for local timezone conversion.

[KelvinTegelaar]

I've added the following code to the beta branch, as some timezone conversion experimentation. It should convert the UTC time to the localized time.

I'm not sure if I like it though.

                if ($items.items) { 
                    foreach ($item in $items.items) {
                        foreach ($date in $item.psobject.Properties | Where-Object { $_.name -like '*date*' }) {
                         $ConvertedDate = [System.TimeZoneInfo]::ConvertTimeBySystemTimeZoneId([datetime]$date.value, (get-timezone).id).ToString('yyyy-MM-ddTHH:mm:ss.fff')
                         $item.$($date.name) = $ConvertedDate 
                        }
                        $item
                    }
                }
                if ($items.item) {
                    foreach ($item in $items.item) {
                        foreach ($date in $item.psobject.Properties | Where-Object { $_.name -like '*date*' }) {
                         $ConvertedDate = [System.TimeZoneInfo]::ConvertTimeBySystemTimeZoneId([datetime]$date.value, (get-timezone).id).ToString('yyyy-MM-ddTHH:mm:ss.fff')
                         $item.$($date.name) = $ConvertedDate 
                        }
                        $item
                    }

It's somewhat hacky and we're approaching it by converting anything with date right now, that will need cleaning up too.

Is this something we want to do? Using [System.TimeZoneInfo]::ConvertTimeBySystemTimeZoneId([datetime]$date.value, (get-timezone).id) we do prevent DST issues too.

In case we'll add this, we would need to do the same for any time-based input.

[KelvinTegelaar]

@klemmestad Let me know what you think of this approach, there's a lot of caveats regarding time and I know you've went down this path before. :)

[Hugo Løvhøiden Klemmestad]

Timezones are a pain! What I ended up doing was to convert any date where $DateTime -ne $Datetime.Date. The objective was to leave any dates (i.e. a datetime field with 00:00:00.000 as time) unchanged. If we go down this path (and I think we have to), we'll have to include code to reverse any datetime changes when an updated object is posted back to the API.

There is another issue with this that I haven't figured a way around yet: What about tenants that are using multiple timezones? I have an open issue on my module for a US company with departments both i Eastern and Central standard time. When a user in CEST tries to query for time entries for a given date the result is different, depending on which timezone the query was made from. This is by design, of course, but is it the correct approach? Is it even possible to solve it?