Rest API Datetime mismatch P10

  

Hi guys.

We're getting a problem with date time values used on a Rest API.

What is happening is that we have a Rest API built on a P9.1 platform that exposes a method that I'm consuming on a P10 platform on different servers and, without doing neither an explicit format nor a conversion, I'm getting different values for date times attributes.

In the output of the Rest API method, during debug, I can see the correct value being return (see Pic1 in the attachment):

#04/12/2017 10:00:00#  and  #04/12/2017 11:00:00#


However, after synchronizing the data with my mobile application local storage and, by inspecting the WebSQL and the displayed values on the screen, I can see a difference in terms of hours for both cases (see Pic2 and Pic3 in the attachment):

In the Web SQL: 2017-04-12 14:00:00 and 2017-04-12 15:00:00 


In the screen (only showing hours here, by requirement): 03:00PM _ 03:00PM


Did anyone had this problem and was able to fix it. This seems to be a bug or at least a problem maker from the platform by doing this kind of conversions. 

Hi Gonçalo,


Most of it look just like timezone conversions.

From the first screenshot I would say that your server is in a UTC-4 timezone. The values that you see in the debug are in your server timezone.

On the second screenshot, the dates that are stored in WebSQL are always stored in UTC (and then converted when read).


Now the tricky part is the last screenshot ... For that to be correct you would have to be in a UTC+1 timezone (if I didn't mess up my math). 

If that is not the case, you will need to either upload a sample that replicates the problem or show us a bit more the queries, variable types and expressions involved into displaying those dates.


Also is the REST API relevant here? Is that first screenshot from the server that is exposing it or consuming?


Edit: from your profile I see that your location is Lisbon, so the UTC+1 would also make sense.

Do you still need more help on the subject? Looks all correct to me.


Regards,
João Rosado

Hi João.

First of all, thank you for your reply.

The scenario you just described is exactly what is happening.

But the problem is exactly that since I don’t want any time zone conversions on the middle.I want that the date time I receive should be the same I’ll use on the local storage.
Meaning, everyplace in the world where I use the app, should use the hour set for each tenant on the Tenants timezone, without having to convert those, since the Rest API already deals with that rule.

The workaround we discussed was saving the dates as text and using conversion functions, but it’s somewhat ugly. Also, we want to filter records by date, so having unexpected conversions between the UI and the local storage makes that unreliable.

I don’t like the way the platform are dealing with this automatically because we lose control. We should at least have an option to disable it.

This being said, for the requirements I just described, could you point us the best way (in terms of performance and code maintenance) to deal with this?


Regards,

Gonçalo Martins

Solution

The recommended way to do it is to save separate fields for the Date and the Time since those do not have automatic conversions.


Also note that the REST API also does conversions to local timezone, so if you say that it treated at the REST API, is it assuming that both servers are in the same timezone?


There is no way to disable the default behavior as it would cause more problems that the ones it would solve. I understand that it makes it a bit harder for the use case of forcing a specific fixed time that does not depend on the user location, but that is the easiest one to solve at the applicaton level.


Regards,

João Rosado

Solution

Thanks a lot for the help.

In fact, that was actually the way I started trying this morning and that way, according to your recommendation, I'm on the right path.

Regards,

Gonçalo Martins  

By the way, is there any place on the documentation where we can read more about this behaviour?

João Rosado, you mentioned the REST API also does timezone conversions. I do not find entirely unexpected that a consumed REST method converts a datetime value that contains timezone information to the server's timezone, but does an exposed REST API also convert its datetime values? If that's the case, does it assume the input date is using the server's timezone, or does it assume it's UTC?

Hello Gonçalo,


Unfortunately we don't have public documentation describing the timezone conversion mechanisms yet. We had an issue in our backlog to address this and I'm now adding the feedback contained in this thread as valuable information that will help us prioritize the issue.

João Pedro Abreu wrote:

João Rosado, you mentioned the REST API also does timezone conversions. I do not find entirely unexpected that a consumed REST method converts a datetime value that contains timezone information to the server's timezone, but does an exposed REST API also convert its datetime values? If that's the case, does it assume the input date is using the server's timezone, or does it assume it's UTC?

DateTimes inside OutSystems logic are always in he local server timezone (unless some cases where they are created inside extensions ..but lets not go there). When that DateTime reaches a Exposed REST it is converted to UTC and sent with timezone information ("Z").

That way any system that consumes that API will be able to correctly interpret that DateTime correctly without having to know your server timezone.


Just like in the mobile, that behavior covers correctly most of the use cases. The reminder edge cases can be covered by using either Date, Time or Text datatypes.


Regards,

João Rosado