Author Posts

November 12, 2014 at 8:19 am

I'm sure there is some easy resolution for this, but my coffee hasn't kicked in yet...

My script needs to pull back remote session information from a Horizon View VDI environment and output a table showing the username, VDI pool, VDI name, and how long the user has been logged in. Most of that has been no problem, but I want the logged in duration column to be sorted.

From this code you can see that Get-RemoteSession returns 2 properties that can be used to create that column: startTime and duration. Unfortunately, neither of those are in a format that is sortable...

PS C:\scripts> Get-RemoteSession -username domain.com\user1 | Select-Object Username, pool_id, DNSName, starttime, duration


Username  : domain.com\user1
pool_id   : network7vm
DNSName   : NETWORK7VM2.domain.com
startTime : Thu Sep 11 10:29:33 CDT 2014
duration  : 62 days 0 hours 41 minutes

Using ParseExact, I can convert startTime to a DateTime object, which is sortable.

PS C:\scripts> [datetime]::ParseExact("Thu Sep 11 10:29:33 CDT 2014", "ddd MMM dd HH:mm:ss CDT yyyy", $null)

Thursday, September 11, 2014 10:29:33 AM

The problem, though, is that some of the users are coming back with "CST" instead of "CDT" for the time zone, (I realize that probably indicates another problem with NTP somewhere in the View environment, but I'll mess with that later...). How do I convert that startTime field into a DateTime when the time zone abbreviation isn't consistent?

Thu Sep 11 10:29:33 CDT 2014
Wed Nov 12 07:11:51 CST 2014

November 12, 2014 at 11:51 am

You could split the string and test the appropriate element. Like this

$data = @("Thu Sep 11 10:29:33 CDT 2014", "Wed Nov 12 07:11:51 CST 2014")
$data | foreach {
$rst = $psitem
$time = $psitem -split " "

switch ($time[4]) {
"CDT" {$date = [datetime]::ParseExact($rst, "ddd MMM dd HH:mm:ss CDT yyyy", $null); break}
"CST" {$date = [datetime]::ParseExact($rst, "ddd MMM dd HH:mm:ss CST yyyy", $null); break}
}

$date
}

November 12, 2014 at 2:05 pm

Well, I was hoping to come up with a way to make it more portable, (i.e. other time zones), but that should work for now. Thanks!

November 13, 2014 at 12:24 pm

Add more options into the switch!

November 16, 2014 at 3:57 am

Here's a version with less typing and dynamic support for an infinite amount of potential time zones (although that amount should be finite in our world 😉

PS C:\> $data = @("Thu Sep 11 10:29:33 CDT 2014", "Wed Nov 12 07:11:51 CST 2014")
PS C:\> $data | %{ [datetime]::ParseExact($_, "ddd MMM dd HH:mm:ss $(($_ -split '\s+')[-2]) yyyy", $null) }

Thursday, September 11, 2014 10:29:33
Wednesday, November 12, 2014 07:11:51


PS C:\>

November 18, 2014 at 9:30 am

That works, Joakim! I see how you did it, and I see why it works... But I would NEVER have come up with that solution! That's just... weird, man! 🙂

And I'm glad it handles an almost infinite number of time zones. That makes it easier to manage all of those parallel universes I work in.

November 18, 2014 at 11:38 am

Such words can fill a man's heart with momentary joy (I wanted it to sound profound and poetic : P ). Thanks.

Another planet or (large) moon should be enough to warrant its own time zones – I don't quite think you need an entire parallel universe!