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

DateTime without TimeZone management

DateTime without TimeZone management

It should be possible on thingworx to show/manage a date-time value without the hour-shift caused by the timezone of the user web-browser.

As you know date time works internally as UTC, but when it is rendered to the browser, the hour is shifted to the timezone of the computer running the web browser. If you change the timezone of the computer, the shown time will change !

 

We have for example an external SQL with date-time values. if we keep those data on a DATETIME object (using a datashape), when it is shown on the browser the time (hour) will change due to user timezone.

We want instead to show those date-times as they are on SQL.

To do that I have to convert date-time into strings, and so shown as string, but it will limit a lot the functionality.

 

It could be made may be in two ways.

- adding on the DATETIME formatting option (yyyy MM dd ...), a new tag (NOTZ?)that disables the timezone shift when data is rendered on the browser

- create a new DATETIME_NOTZ variable type that to the same thing

 

An attention should be made on date-time widgets (date-time picker time-selector etc...), may be those need to have a flag the disabled date-time timezone shift on the "reverse side" (browser to thingworx).

May be a new variable type DATETIME_NOTZ could be a more flexible and system-wide feature. All mashup objects using this variable wont make timezone-shift

 

 

8 Comments
CarlesColl
18-Opal

TimeZone management it's an old missing feature in ThingWorx. But shouldn't be implemented how you say here. Actually TW doesn't manages internally DateTime objects in UTC, seeing in UTC it's just becouse your server/tomcat it's set at UTC if you set your server at another timezone at server side it will show up on the Server's TimeZone, another different thing it's how it stores it.

 

The right direction of solving this big missing feature it's the ability to bind TimeZone to Widgets, as showing timestamps on a TimeZone it's a conversion job not an storage job. That will allow you to set UTC for showing data, and other people to set for instance device/thing TimeZone instead of browser TimeZone(which doesn't makes any sense on a Thing's World and it's the actual solution...).

 

We had to modify all standard DateTime related widgets in order to have this feature, we already offered to ThingWorx a while ago (more than 2 years) to make it public available but non interest, still don't know why.

 

There's already Jira tickets on R&D side pointing to this solution:

Also there's a lot of community questions on this just look for it.

 

Just my two cents.

geva
14-Alexandrite

Completely agreed Carlos.

 

Also from my perspective this is a big area where ThingWorx needs work - especially as we have more and more global deployments where things such as local time, time zone selection, and mutli-zone date times need to be handled.

azoorob3
13-Aquamarine

I agree with you both. ThingWorx absolutely needs better time zone support, especially as they are increasingly marketing the product as a single instance solution for global enterprises. It's pretty hard to believe that there's is no out of the box support for this in 2020, and it's a major deficiency in the platform.

olivierlp
Community Manager
Status changed to: Under Consideration

"If we understood the question correctly, then here is I'd break it up:
Sending dates/times from server to the browser
Currently, the server always sends UTC date/time values to the browser which we do not plan to change
Rendering dates/times on the browser
We will consider for future release to provide improved support here
Sending dates/times from browser to the server
Currently, the server always sends UTC date/time values to the browser which we do not plan to change"

geva
14-Alexandrite

Hi Olivier,

I'm happy to hop on a short call to discuss this shortcoming with yourself or product management.  It is not as simple as just the question of how time zones are addressed in the browser.  It is required to also have timezone services available in the platform in order to address various scenarios around how you handle data inside services, do calculations, etc.  For example applying a shift schedule to a set of plants where you have connected machines - the shift is in local time however the data from the machines are in UTC.  You need to start by identifying and storing the local time offset from UTC for connected assets - this would need to be a part of RemoteThing.... perhaps even GenericThing as something like a Site clearly has such relevant context.

Greg

iguerra
14-Alexandrite

Hello @geva  

yes timezone is not easy to manage ... I still have some little troubles even now...

(There is moreover the dailyght saving hours that adds troubles!!!)

I created a timezone_functions thing to manage this
I use GPS location to extract timezone of each thing/plant (there are free services available on the web to do this)

timezone could also be set manually for a thing/plant ... I have lot of things all around the world so I use GPS it was just more easy, and non need to set TZ for each device

 

by knowing timezone I can launch services at specific time for each timezone (I close daily data calculation at midnight for each timezone ... so I do this every hour but only for things on a specific timezone). 

 

Anycase I agree that platform timezone service could be useful

 

@olivierlp 

I agree on you points, but on you last title Sending dates/times from browser to the server

I think we are speaking of timeselector and datetime picker widgets . when used linked to services, for queries... right ?

yes ... all data can be considered as UTC, but all widgets that can handle timestamps should have the same "new feature" to manage timezone shift.

That is all who will render timestamp to browser (value display, labels ... grids..and possible also timeseriescharts ) , and also those who allows to choose a timestamp on browser for sending to server. 

cbaldwin
13-Aquamarine
Status changed to: Under Consideration

Under consideration for 2022 release.

olivierlp
Community Manager
Status changed to: Archived

Hello,

We are archiving your idea as part of a general review. This action is based on the age of your idea and the total number of votes received, as per this announcement.

You can always post a new idea with all the details required in the form.

Thank you for your participation.