DiffDays client side vs server side

DiffDays client side vs server side

  

Hello,

I am having a strange situation on my mobile app.

I am using the function diffDays on server side and client side. Server is .NET.

Both the device and the server are on the same timezone.

They return diferent results:

Client side


Server Side

*myDate is currdatetime() 

On both I have exactly this call: 

DiffDays(currdate(), #2019-5-1#)


Client side: 158 days

Server side: 159 days


Could this be a bug?


Thank you

Hi Maria,

Could you show the code were you submit the value to the test local variable? It's easy to understand the context. ;)

Best regards,

Ricardo

Ricardo Pereira wrote:

Hi Maria,

Could you show the code were you submit the value to the test local variable? It's easy to understand the context. ;)

Best regards,

Ricardo

Hi Ricardo,

I put the code in the post above. It's a simple assign. :)

Thanks


Maria João Portela wrote:

Ricardo Pereira wrote:

Hi Maria,

Could you show the code were you submit the value to the test local variable? It's easy to understand the context. ;)

Best regards,

Ricardo

Hi Ricardo,

I put the code in the post above. It's a simple assign. :)

Thanks



Hi Maria,


You have there the assign to "datediff". What I mean is the code where you manipulate the local variable "test". :)

Hello Maria,


I was very curious about this question that I ended up testing everything by myself hehe
I found out that the DiffDays() functions works very well, the problem is the Time Zone, I know you said that both Server and Device are in the same Time Zone but according to OutSystems documentation:


"... The Time component you provide in the parameters will be ignored. The DiffDays function receives two Date Time parameters, and then replaces the Time component with 00:00:00. It calculates the elapsed time in milliseconds from the first date at 00:00:00 to the second date at 00:00:00, and then converts the difference in milliseconds into days.
The DiffDays function behaves differently depending on the application server you are using because Daylight Saving Time (DST) is considered in the J2EE server while in the .NET server DST is ignored. Note that the time zone considered for evaluating this function is always the time zone of the Platform Server, regardless of the regional settings of the end-user."


I did a small POC to test this using the same dates as you did but instead of working with DiffDays() I used seconds: https://simoessalvador.outsystemscloud.com/TestDiffDays/Screen_Phone

Please let me know if it helps you.

KR,
Ruben Bonito



Hi,


Can you make it it output the result of "DiffDays(#2018-11-23#, #2019-5-1#)"?

Is it also inconsistent between client and server?


(Also what versions are the server running at?)


Regards,

João Rosado

Just tested on my personal environment and it does indeed to have a bug/inconsistency there.

The client side is taking into account the DST that exists 2019-05-01 but the server side does not. (similar to the difference between java and .net that is documented). Note that the DiffSeconds has exactly the same behavior, but it returns 158.95 on your example (adding an extra hour returns 159.0)


I'll ask around on Monday if this is expected behavior and just needs updated documentation for the client side behavior or if it should be considered a bug. Also I'm not sure it can be fixed on a revision due to it being a potential breaking change.


Regards,
João Rosado

Hey João,

Just saw your reply now, looking forward to hear from you again regarding this topic.

KR,

Ruben Bonito

Hello,

Thank you for the replies. 

João, I will wait for your update!

Best regards,

Maria João Portela


Hi,


Sorry for the delay.

We had a talk internally and agreed that since the method is meant to ignore the "Time Component" it does not make sense to take into account the DST changes (current .NET Server behavior).


But like I said, since this is a potential breaking change it's still being reviewed on the impact.

The responsible of the area will reply here when he has a decision.


For the time being I think a good workaround is to use in client side:

"Trunc((DiffHours(CurrDate(), #2019-5-1#) + 1) / 24)"

Note: this will work even after a fix is made but assumes that both arguments are "Date", so without Time components.


Regards,
João Rosado

Hi,


Just to let you know that this is indeed a breaking change and we can only release a fix in a major version. For now you can use the workaround provided by João Rosado.


Best Regards,

Carlos Xavier

Hello,

This was a weird one!

Maybe you could put that information in the function description since a major release might take some time and there is already an explanation of difference between stacks:


Thank you!

Maria João Portela