Hi Mykola,

Are you using DateToDateTime?

Regards

Hi Paulo, 

No. In this case it is direct assign of date value to DateTime variable. As you can see on screenshot date value is result of local aggregate. 

Yes it has same problem - tried with two variables of dateTime type and one assign directly and another with dateToDateTime applied - same result.

I've tried play with timezone set on computer and it affects this directly... setting my timezone to -1 now gives correct result #2018-9-4 00:00:00#.... but setting it even further to -4 and DateTime shifts as well.. 

There is documented "bug/feature" that changes DateTime variables values when sending it to server from device but in this case it never leaves the device so I can't understand why this should be related to local timezone setting? And there is no warning on ServiceStudio at all when performing such assign  probably because it shouldn't happen.

@Mykola

I believe what you are experiencing is documented here.

"When writing the null DateTime value from local storage or saving it to the local storage, as well as when sending it to the server, the time and date are adjusted for the time zone difference in relation to the UTC time."

Hi João,

That seems related but it is not a nullDate value and value was not send to server either.

Hi Mykola,

A Date Variable, when assigned to a DateTime, is assigned as the Date with a time component of 0:00 (midnight). Since the Local Storage stores values in UTC, a date of, say, 2018-09-05, is actually stored as 2018-09-05 00:00 UTC. When retrieving dates from an Aggregate (including when assigning), they are converted to local device time, which in your case is apparently UTC+1, which explains the conversion.

I do agree though this is probably unwanted in this case, and given that in the past there were a lot of problems with Date Times on Mobile (I've submitted quite a number of bugs myself), what happens here might not be by design, and may indeed be a bug. I'd therefore advise you to send an error report to OutSystems Support, so they can take a look at it.

Hi

All date / time data types are internally stored as datetime.

The timezone conversion is by design and is documented. See here ;)

https://www.outsystems.com/forums/discussion/27205/datetime-variables-changes-when-passed-from-client-to-server/

Eduardo,

They are, but they're also on Web Apps. The interesting thing is that they are stored in UTC, but afaik except if they are Dates. Leading to the troubles Mykola is having. It's interesting though that he's having a problem that he's had before, and apparently forgot all about it :).

Hi Killian,

It is not the same problem :) That was conversion happened when exchanging DateTime variables between server and device and logic of conversion between UTC made sense.

In this case it never leaves the device and value is stored in local entity as date "2017-01-02"  (is there a way to see if this is what is stored in local entity or it is UTC format as you suggested?)

Well, they're definitely stored as UTC, you can most easily see this when testing your app in Chrome.

Sorry, but how do you mean testing? In Application local database on chrome dev tools I have no indication of UTC format or time appendix. Where can I see that format to confirm underlying logic.

Hi Mykola,

I created a small test app, having the following:

1. A Local Entity with two Attributes: Date and DateTime.
2. A Screen with an OnInitialize creating three records:
   1. CurrDate() for both Date and DateTime;
   2. CurrDate() and CurrDateTime() for Date and DateTime respectively;
   3. A hardcoded date (#2018-09-05#) for both.
3. A List Widget on the Screen showing:
   1. The Date;
   2. The DateTime;
   3. A DateToDateTime() of the Date.

This is the result:

Local Storage shows the Date being stored as-is, but the DateTimes converted to UTC (I'm at UTC+2):

The List Screen shows everything as expected:

Note that when debugging however, the UTC time is still shown:

Thanks for testing. Can you please share oml so I can add local variable too and see if that will leave same way. Also will check if the result the same on our platform version (I'm currently have no access to see version).

Here it is (if it uploads at all, I've been seeing some upload problems on the forum today).

Thank you for sharing oml

I didn't have possibility to test it yet but it is not forgotten :)