Skip to main content
S
steve23714-Alexandrite
14-Alexandrite
August 11, 2023
Solved

GetTimeZoneInfo service in PTC.Base.CommonHelper

  • August 11, 2023
  • 1 reply
  • 1166 views

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

 

Best answer by 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

 

 

1 reply

S
steve23714-AlexandriteAuthorAnswer
14-Alexandrite
August 14, 2023

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

 

 

    Terms & ConditionsCookie settingsAccessibility statement