Skip to main content
Anonymous
January 24, 2017
Question

Problem with timestamp in widget Data Export

  • January 24, 2017
  • 5 replies
  • 2671 views

Hi All,

we use a cloud for thingworx thatis located in US (GMT -5 EST).

Users are in Italy.

Data extracted using the QueryPropertyHistory service (by Start and End time) are visible in a grid, and the timestamp value is correct (shown in italian time zone).

When the same data are binding to the 'Data Export' widget , the timestamp value in the result file is not correct as it is in US time zone (server timestamp)

How can we create an export file with the correct timestamp, that is the one of the user (italian)?

BR

Dimitri

5 replies

jkaczynski1-Visitor
1-Visitor
January 24, 2017

Hello Dimitri,

I believe there is no OOTB way to do that. The only reason that it's displayed correctly, is that browser timezone adjust the timestamp. But the export itself is done on the server side, so - using the US timestamps.

However, you can easily create your own custom service to export data to csv. Your service should iterate over InfoTable, adjust the timestamp, create an csv file in the Thingworx repository and then returns a downloadable link (from the repository service GetFileListingWithLinks). Then you need only to bind the result Hyperlink to the Navigation widget, invoke Navigate service of that widget with ServiceInvokeCompleted and - download a ready file.

If you pick this way, don't forget to clear the repository from time to time.

Hope it helps, if you have additional questions, don't hesitate to ask.

Regards,

J.

ttielebein5-Regular Member
5-Regular Member
January 24, 2017

Have you seen this similar use case?

Hope this helps!

Tori

jkaczynski1-Visitor
1-Visitor
January 25, 2017

Hi Tori,

I believe the localization tokens don't have impact on the timezone timestamp adjustments. Or am I wrong? I've read this use case and haven't found a solution that would work for Dimitri.

CarlesColl1-Visitor
1-Visitor
January 25, 2017

Hi Jakub,

You are right, Localization Tokens have nothing to do with TimeZones.

And by the way, it's not that easy as you described, as for instance his users timezone it's Italy which has Daylight Saving Time. If he want's to do it right, he will need to build a Java extension to leverage TimeZone features which came with Joda Time library, that way he will be able to translate correctly at server side to the correct TimeZone format.

This problem with the Extension Widget, which it's incoherent with the rest of user interface  ( as all the user interface works on User Browser TimeZone ), I've notified to TW but they just said it works as specs

I've been pushing them hard the last Year and a half to have right TimeZone support, but they aren't on track and there isn't anything on the Roadmap as far as I know.

Carles.

    jkaczynski1-Visitor
    1-Visitor
    January 25, 2017

    Hi Carles,

    Thanks for the update, it's good to know what is the status. And you're right, to create such service - and to make it generic to be able to re-use in a different time zones - one needs a lot of work. But it's not a hard thing if you have only one time zone (with DST adjustments). It's possible even in JavaScript. But, of course, in Java it's a lot easier, faster and less error-prone!

    Terms & ConditionsAccessibility statement