Log in to AnswerLog in to Follow
Peter Mudde
20Views
6Comments
Solved
[Reactive app] Disable showing dates in client timezone
Question
Reactive
Timezone
Application Type
Reactive

According to this article, in Reactive apps datetimes are always UTC, unless you show these dates in the UI.

This is problematic for an application, in which the user can see multiple plants around the globe in the dashboard and he/she wants to see the data in the timezone of the location itself.

Is there a way to overwrite or disable the client timezone conversion in Reactive apps?

0
0
on 1st Apr
Peter Mudde
Solution

At this moment, there is not a nice way of disabling the default conversion of UTC to Client Timezone in Reactive Apps. In our app, we will compensate on the server side for the difference between 'location timezone' and 'client timezone', by reading the TimezoneOffset onInitialize.

I have proposed an Idea. If more people support this idea, please like and vote for this idea here: https://www.outsystems.com/ideas/10564/make-datetime-conversion-to-client-timezone-in-reactive-apps-optional


See solution in context
1
0
10 days ago
Kilian Hekhuis
mvp_badge
MVP

Hi Peter,

To my knowledge there is no such thing. But, if you would disable the timezone conversions, you'd end up with times in UTC, so you still wouldn't be able to see the data in the timezone of the location.

1
0
on 1st Apr

Disabling the client side conversion will be enough.

On the server side, we convert general utc date times in our database to 'local date times'.
So the conversion is handled manually, which gives us all options we need.

Thanks for the reply.

0
0
on 1st Apr
João Marques
mvp_badge
MVP

Hi Peter,


A workaround I used for it, was to pass the date time and time attributes between client actions and server actions as text and then converting back to date time and time using built-in functions like TextToDateTime() or DateTimeToText(). On queries, I would add an attribute which would have DateTimeToText(<Attribute>) and convert it back to datetime before showing on the screen.


It is a workaround, not a very elegant workaround but it worked.

I am actually wondering if there is a better solution for that.


João


2
0
on 1st Apr

Thanks for your reply Joao!

Problem I foresee with this solution is that we use the datetimes in an Highchart.
In that context, we want to keep the datetime type so Highcharts work correctly.

Another solution we came up with, is converting the datetimes on the backend to compensate for the difference in timezone of the client.

So for example
- UTC: April 2nd, 2021 at 14:00
- User: in timezone +02:00
- Location: in timezone -05:00

On default this date would be shown as 16:00 to the user in +02:00.
But what we actually want is to show it as 09:00 to the user, based on the location of -05:00.

The difference between client and location (in total 07:00) can be subtracted from the UTC time. The new "UTC" time will be: 14:00 - 07:00 = 07:00.

If you have a UTC of 07:00, to the client in timezone +02:00 this will be shown as 09:00.
And that would be what we want as time of the location.

The one thing to get this working properly, is retrieving the client timezone settings correctly.

0
0
on 2nd Apr
Kilian Hekhuis
mvp_badge
MVP

Replying to Peter Mudde's comment on 02 Apr 2021 08:32:57

Luckily, that is as simple as:

offset = new Date().getTimezoneOffset()
1
0
on 2nd Apr
Peter Mudde
Solution

At this moment, there is not a nice way of disabling the default conversion of UTC to Client Timezone in Reactive Apps. In our app, we will compensate on the server side for the difference between 'location timezone' and 'client timezone', by reading the TimezoneOffset onInitialize.

I have proposed an Idea. If more people support this idea, please like and vote for this idea here: https://www.outsystems.com/ideas/10564/make-datetime-conversion-to-client-timezone-in-reactive-apps-optional


1
0
10 days ago
Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.