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?
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
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.
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.
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
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.
Luckily, that is as simple as:
offset = new Date().getTimezoneOffset()
we faced the same problem and what we did was transforming the datetime variable into a text variable at client side
TextDate = DateToText(DateTimeToDate(DateTime))+ " "+TimeToText(DateTimeToTime(DateTime))
pass the TextDate variable as text to a server action, convert it back to datetime and save.
Just wanted to add a similar scenario for those who come across this.
I was pulling a DateTime field from an external (non-OutSystems) database. I had a structure with the corresponding field set as Date. I set my structure field equal to DateTimeToDate(ExternalDtTmField) but this did not work. What I ended up doing is adding a custom attribute on the aggregate that did what Joule describes: "DateToText(DateTimeToDate(ExternalDtTmField))" then set my structure field to be Text data type. Then I set the structure field equal to that custom attribute.
Had a similar issue using TextToDateTime() when pulling data from the Health & Fitness Plugin. The dates from the plugin are already in UTC, and TextToDateTime() looks like it tries to convert the date to UTC again, setting everything back by 2 hours (we're UTC+2)
Joule's solution worked for us. Pass the date as text to the server then there is no adjustment on the date.