Skip to main content
R
Radu15-Moonstone
15-Moonstone
August 23, 2019
Solved

Thingworx server time different to local time.

  • August 23, 2019
  • 3 replies
  • 7639 views

Hello. The problem layout is simple: I have a service that returns the current time. The code would be the following:

var d = new Date();
result = d;

This shows the browser's time (for example, 11:50:23). However, if I execute this:

var d = new Date();
var hour = d.getHours();
result = hour;

It will show me the server's time (which happens to be one hour behind, so it shows me 10).

 

Does anyone have any way of approaching this issue, so it would not display the server time, but actually display the actual present time of the browser? Thank you.

Best answer by Constantine

Hello Radu,

 

Unless you implement it, the backend doesn't know anything about your client's timezone. It is not specific to ThingWorx, just the way web apps work. There's nothing in HTTP standard that supports automatic exchange of timezone data. Generally speaking, there are two alternatives:

 

  1. Handle timezones on the server side (often can be avoided, and not recommended unless you really need it). In ThingWorx it usually means making time zone explicitly configurable on the User level, i.e. add the corresponding field to the UserExtensions thing shape, implement some logic for initializing and validating it, create a mashup for selecting it, etc. Once you have it, you'll be able to do all date/time operations in the user's local timezone. You usually go for this option when you need to format your date/time as strings to send them out of the system (email, SMS, log files, etc.) Here we only scratch the surface, because if you operate internationally and want to do it right, you'll also need to store some regional settings like local date/time formats (e.g. YYYY-MM-DD vs MM/DD/YYYY).
  2. Offload all timezone handling to the client side (browser, external mailing system, etc.) In ThingWorx you can do most of the date/time formatting work directly inside your mashups. Just return DATETIME objects whenever possible and make the browser do all formatting work for you. It will use user timezone automatically.

Obviously, option (2) is way simpler and more reliable than (1). 

 

Regards,
Constantine

3 replies

S
slangleyCommunity Manager
Community Manager
August 23, 2019

Hi @Radu.

 

Could you please provide the version of ThingWorx you're running?  We would like to do some testing around this.  Also, have you tested with multiple browsers with the same results?

 

Regards.

 

--Sharon

R
Radu15-MoonstoneAuthor
15-Moonstone
August 24, 2019

Hello @slangley ,

 

I am using Thingworx 8.4.4. I have also tried on Firefox and Edge, but the problem still persists.

S
smainente16-Pearl
16-Pearl
August 23, 2019

Hi Radu,

 

ThingWorx Javascript services are always executed on the server.

 

I suspect that your first service is returning a TIMESTAMP primitive type (its value is the number of milliseconds since the Unix Epoch). Knowing that it is a TIMESTAMP,  the Thingworx client (Composer / mashup) is able to render it as a Date using the local timezone.

 

I suspect that your second service is returning a INTEGER or NUMBER primitive type. The Thingworx client (Composer / mashup / ... ) will display this value as it.

 

You have two options :

- return a timestamp (your first service) and extra the hour on the client

- or send the client timezone information to the service as argument

The solution may depend on your client capability (Mashup, REST call, Edge SDK, ...)

R
Radu15-MoonstoneAuthor
15-Moonstone
August 24, 2019

Hello,

 

Thank you for your reply. Hardcoding the time difference on the service is not a good solution, because the server I am working on is different to the server that the service will be deployed on.

 

I thought to use timezone information before to adjust the time. But I'd rather not have the client timezone as a service parameter, instead I'm trying to figure out how to calculate the difference in time between the server time and the local time, and eventually implement that into code. Because the new Date() constructor returns the local time, while the getHours() method returns the server time hour.

C
Constantine18-OpalAnswer
18-Opal
August 26, 2019

Hello Radu,

 

Unless you implement it, the backend doesn't know anything about your client's timezone. It is not specific to ThingWorx, just the way web apps work. There's nothing in HTTP standard that supports automatic exchange of timezone data. Generally speaking, there are two alternatives:

 

  1. Handle timezones on the server side (often can be avoided, and not recommended unless you really need it). In ThingWorx it usually means making time zone explicitly configurable on the User level, i.e. add the corresponding field to the UserExtensions thing shape, implement some logic for initializing and validating it, create a mashup for selecting it, etc. Once you have it, you'll be able to do all date/time operations in the user's local timezone. You usually go for this option when you need to format your date/time as strings to send them out of the system (email, SMS, log files, etc.) Here we only scratch the surface, because if you operate internationally and want to do it right, you'll also need to store some regional settings like local date/time formats (e.g. YYYY-MM-DD vs MM/DD/YYYY).
  2. Offload all timezone handling to the client side (browser, external mailing system, etc.) In ThingWorx you can do most of the date/time formatting work directly inside your mashups. Just return DATETIME objects whenever possible and make the browser do all formatting work for you. It will use user timezone automatically.

Obviously, option (2) is way simpler and more reliable than (1). 

 

Regards,
Constantine

R
Radu15-MoonstoneAuthor
15-Moonstone
August 26, 2019

Question: If I do this:

var d = new Date();
result = getUTCHours() - d.getTimezoneOffset() / 60;

it seems to return the exact hour that I intend. Does this work everywhere, though?

C
Constantine18-Opal
18-Opal
August 26, 2019

No, what you're doing here looks strange and probably works by accident. Assuming that your server is in UTC+2 timezone, what you are getting here is hours in UTC-2, which doesn't make sense and won't work for users in UTC-1 for example.

 

Again, to summarize, you either need to pass the user's timezone to the server side somehow, or you need to do all those calculations on the browser side, i.e. in the mashup. You cannot format date/time in the user's timezone on the server side without knowing his timezone, it's that simple.

Terms & ConditionsCookie settingsAccessibility statement