cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Did you know you can set a signature that will be added to all your posts? Set it here! X

GetTimeZoneInfo service in PTC.Base.CommonHelper

steve237
12-Amethyst

GetTimeZoneInfo service in PTC.Base.CommonHelper

For the american eastern time zone, the UTC Offset is -5:00 during standard time and is -4:00 during daylight saving time.  For this year, Daylight Saving time started at 2:00am on 3/12/2023 and ends at 2:00am on 11/5/2023.  So, I expect that this service should return -4:00 for this time period and -5:00 for all times before and after those dates.

 

However it actually returns -4:00 between 3/11/23 9:00pm and  11/4/23 9:59pm.

 

So, it's like the service thinks that DST starts at 2am UTC, instead of local time.  So, to figure the offset it converts the given time to UTC and if it is between 3/12 2am UTC and 11/5 2am UTC it returns -4:00.

 

Here's a screen shot of the service:

steve237_1-1691786681862.png

Am I correct in thinking the service doesn't work properly?

 

Thanks,

Steve

 

1 ACCEPTED SOLUTION

Accepted Solutions
steve237
12-Amethyst
(To:steve237)

The serice is working properly.  I failed to consider that my laptop is running on Eastern time, but our thingworx platform is running on UTC.  The dateTime input parameter is a DATETIME base type, so Thingworx will consider the value I enter in the service test window to be in Eastern Time and convert it to UTC before running the service.

 

For example, when I enter dateTime = 3/12/2023 1:59 am and timeZoneId=America/New_York (one minute before DST began this spring), I originally expected the service to return -05:00 as the utcOffset.  However, Thingworx converts dateTime 5 hrs ahead to 3/12/2023 6:59 am and then runs the service.  The service correctly returns -04:00 because the conversion put the dateTime within DST.

 

To prevent the conversion, the service probably should have been written with the dateTime parameter as a STRING Base Type instead of DATETIME.  However, I can write a local service with a STRING dateTime input parameter, then use the parseDate() script function to convert the string to DATETIME format.

steve237_0-1692044076489.png

 

 

View solution in original post

1 REPLY 1
steve237
12-Amethyst
(To:steve237)

The serice is working properly.  I failed to consider that my laptop is running on Eastern time, but our thingworx platform is running on UTC.  The dateTime input parameter is a DATETIME base type, so Thingworx will consider the value I enter in the service test window to be in Eastern Time and convert it to UTC before running the service.

 

For example, when I enter dateTime = 3/12/2023 1:59 am and timeZoneId=America/New_York (one minute before DST began this spring), I originally expected the service to return -05:00 as the utcOffset.  However, Thingworx converts dateTime 5 hrs ahead to 3/12/2023 6:59 am and then runs the service.  The service correctly returns -04:00 because the conversion put the dateTime within DST.

 

To prevent the conversion, the service probably should have been written with the dateTime parameter as a STRING Base Type instead of DATETIME.  However, I can write a local service with a STRING dateTime input parameter, then use the parseDate() script function to convert the string to DATETIME format.

steve237_0-1692044076489.png

 

 

Top Tags