Thingworx server time different to local time.

[Radu]

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.

[slangley]

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

[Radu]

Hello @slangley ,

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

[smainente]

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, ...)

[Radu]

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.

[Constantine · Accepted solution]

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

[Radu]

Greetings @Constantine ,

Your answer has been a lot of help, thank you. The problem that I'm dealing with involves option (1), unfortunately, since I have to pass the current date as a string (I have to return it as a string, because I must have the date in the ISO format: YYYY-MM-DDTHH:MM:SS . Only now I noticed that if I return the date as DATETIME, it shows the local time, and when I return the date as a string, it shows the server time), to generate an API link.

Could you elaborate with greater detail on how exactly it can be accomplished using option (1)?

Thank you.

[Constantine]

Radu,

The ISO format for strings also supports time zone designation, i.e. YYYY-MM-DDTHH:MM:SS+hh:mm. If your API supports this format, then you can format your timestamps on the server side, specifying hh:mm as your server offset from UTC (that's what new Date().getTimezoneOffset() gives you).

/ Constantine

[Radu]

Hi,

Sadly, it doesn't support the timezone offset at the end. I will try to figure out how to modify the UserExtensions thing shape. You suggested to add a timezone specific property to the thing shape, but how would that work?

Thank you

[Constantine]

Radu, The user will need to specify his/her time zone when they login (usually we check whether the timezone is specified or not in the Master. If it is not specified -- we invoke a Navigation to display a User Settings popup). So you'll need to create a mashup for the "user settings" popup, create services that will set those values on the user currently logged in, etc. It's not a complex job, but takes some time to implement correctly. Adding a property on the user extensions is just the first step. On the bright side, you'll be able to use the same approach for setting other things about your user, e.g. phone number, email address, language, password, etc. Finally, if you use Projects and Tags wisely, you should be able to export the whole thing and reuse it with minor modifications on your other ThingWorx projects. / Constantine

[Radu]

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?

[Constantine]

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.