Timezones for SDT?

[kelemvor33]

Hi,
What Timezone is used for SDTs when using the New-LMDeviceGroupSDT command? It appears to look at the timezone of the machine I'm on and use that. Is that correct?

E.g. I want an SDT that starts at 5AM Eastern. I'm running the script from a machine that in Mountain. Our Portal timezone is Pacific. I'm located in Central.

When I run the command with 05:00:00, the output shows startDateTimeOnLocal : 2026-02-25 04:00:00 PST. It's using the 5AM as Mountain time and showing it to me in Pacific. When I refresh the LM portal it shows 6AM for me which is really 7AM ET.

It seems I need to put in 3AM since that's what time it is in Mountain when it's 5AM in Eastern. Is that right?

If I then run the script from my own machine it's going to be off by an hour. Is there any way to specify the timezone in the command so if I run it from a different machine it doesn't get messed up?

On a side note, it might be nice to simply specif a Duration instead of having to specify a start and end time. Then if I need to change the time i only have to change it once. And it'd be easier to handle something that crosses past midnight.

[stevevillardi]

I will have to take a look and see how those cmdlets were originally created. I believe they originally supported timezone but were refactored at some point to convert the date times to UTC to machine independent but it's possible it was not done properly. It's been a minute since I looked at them so let me take a look and get back to you.

[stevevillardi]

This will be resolved in 7.9.1

[kelemvor33]

I see that the timezone option was added in 7.9.1. However, it appears to not use the standard timezone naming like you get from get-timezone. The doc mentions IANA timezones which I think means the ones like: America/Boise? I tried using a normal timezone like "Mountain Standard Time" but got an error.

Since this is Powershell, is there a reason it doesn't use a regular timezone name?

I basically just want to set a timezone to start Now and last for 2 hours. If I get the current time and my current timezone, I can just add 2 hours and have the three things I need regardless of what system I run it on. But PowerShell doesn't return the IANA timezone info...

PS C:\Windows\system32> get-timezone
Id : Mountain Standard Time
DisplayName : (UTC-07:00) Mountain Time (US & Canada)
StandardName : Mountain Standard Time
DaylightName : Mountain Daylight Time
BaseUtcOffset : -07:00:00
SupportsDaylightSavingTime : True

[stevevillardi]

Mainly because the only format accepted by the LM API is in IANA format. I was planning on using a .NET class to handle the conversion but that would break compatibility with PS5.1+ users so I opted to just accept IANA as the input format to keep it compatible with all versions of powershell.

If you know a reliable way to convert from standard name into IANA then im happy to re look at adding a conversion layer to support it but from what I could tell, the only reliable method relies on .NET 6+ which is not part of PowerShell 5.1.

[kelemvor33]

I was already looking into that. Only thing I found was hard coding a table that would convert between the two.

Since it doesn't matter where in a particular timezone someone is, you could just map "Central Time" to any IANA item that's in Central Time so it wouldn't need to account for the entire list.

I'll just hard code something in for myself and it will get me what I need for now.
Thanks!

[kelemvor33]

I actually just tried with the other type of timezone and got an error:

PS C:\Windows\system32> New-LMDeviceSDT -startdate $now -enddate $later -devicename $servername -timezone "America/New_York"
New-LMDeviceSDT : Cannot validate argument on parameter 'Timezone'. Invalid timezone 'America/New_York'. Please provide a valid timezone ID (for example, America/New_York).

[stevevillardi]

Taking a looking seems like one of the .NET classes im using for validation is not available in the .NET library that ships with 5.1 powershell. The very thing I was trying to avoid with the above...

Sorry about that, let me look at just introducing a mapping table like you mentioned above and I can probably just avoid the whole juggling of timezones entirely. There will be some edge cases where a Windows standard name could potentially map to multiple IANA ids but thats more of an edge case then anything else considering where most LM users are coming from.

[kelemvor33]

There will be a lot of times a standard name will map to multiple IANA names, but it shouldn't matter in the end since they're all the same time.

[stevevillardi]

i pushed out a new version that attempts to resolve the issue if you want to give it a shot. it should be able to resolve both IANA and windows time zone names so something like this should work as well:

New-LMDeviceSDT -StartDate (Get-Date) -EndDate (Get-Date).AddHours(2) -DeviceId 123 -Timezone (Get-TimeZone).StandardName -Comment "Test Windows Local" 

the Start and EndDates are treated as essentially a raw time value with no timezone attached and converted to the proper timezone based on the indicated timezone parameter