How do I display local time instead of UTC?

[tbone7281]

The situation we are encountering is that we are pulling data from Windchill and the date information is stored as UTC.  In Windchill the date displays correctly, as local time, as the customer expects.  However, when we pull that data into Thingworx and display in a grid, the date remains UTC.

Example:  LastModified in Windchill happened 11/06/2020 at 11:31 AM Eastern.  The stored value for the time 16.31, which is correct due to UTC/Daylight Savings.  If you view the date in Windchill, the UI displays 11:31.

Now, if we pull that data into a Thingworx grid, it displays as 16:31.  If we change the localization token to one that incorporates Z (yyyy-MM-dd HH:mm Z), it results in:  "2020-11-06 16:31 -0500"... so it KNOWS what time zone we are in, and whether DST should apply or not.

How do we get it to display "2020-11-06 11:31"?  This doesn't seem like it should be terribly difficult, but I'm obviously missing something.

Thanks,

Tony

[Ciprian-Traian]

Hello @tbone7281,

It would look like the browser converts server time into local time for users logged into ThingWorx in a different timezone than the server hosting the instance.
One way would be to customize the standard grid widget to support a specific timezone.
Can you use a browser which can be set to a different timezone and run it in another timezone (e.g. Firefox):

// Command in Linux (assumes default Firefox installation)
TZ=UTC firefox &

//Command in Windows (modify path if not installed to default location on disk)
SET TZ=GMT-5
"C:\Program Files (x86)\Mozilla Firefox\firefox.exe"

You can check as well How to return timezone difference between Client and ThingWorx server

There is the capability to do a timeshift (Resources["InfoTableFunctions"].TimeShift(params); ) and you define the shift value
You can just create a timeshift service with InfoTable as input.

Hope it helps,

[tbone7281]

Thanks for the response.  Most of the search results I've found so far say similar things, but I think my issue is even more basic.  While the time zone thing could definitely be an issue, the situation we have now is that the server and client machines are actually already in the same time zone.  The server stores as UTC, but the client seems unable to display the time in a localized format.  My understanding is that it SHOULD do this automatically.

I did try your Firefox suggestion for fun, but saw no difference.

[odukiya]

Hello @tbone7281 

If you want to display local user timezone in thingworx you have to take the values in datetime variable .

If you are taking it in string or changing it in string the composer will always shows server timezone rather than the local user.

Let me know if  it doesn't resolve your query and you have further query.

Thanks

Om Dukiya

[tbone7281]

Thanks for the response.  I tried recreating what we are doing for the client locally and am seeing the same behavior.  I *think* we're keeping the data in datetime format as best we can, but maybe this isn't correct:

1.  As I said earlier, the data in Windchill is stored as UTC:  2020-11-06 16:31:19.0  These are "CreatedOn" and "LastModified" attributes so I know they are DateTime.

2.  To pull that data into Thingworx, we are using an InfoEngine task like this:

ieElement.addAtt(new Att("LastModified", currentWorkItem.getModifyTimestamp()));

The call used to include .toString() as well, but I thought perhaps that was negatively impacting how the systems translated the datetime.  While the return in the XML was formatted different, it didn't seem to have any impact on how it displayed in the grid back in Thingworx.

<LastModified javaType="wt.util.WrappedTimestamp" timeZone="+0000">2020-11-06 16:31:19.0</LastModified>

3.  The InfoEngine task is called via a service in Thingworx and returns as an infotable.  The datashape for the infotable specifies that the date fields (CreatedOn/LastModified) are datetime objects.