Datepicker returns minus 1 day

[JonathanGibbs]

Working with Powerapps 2.0.460, Windows 10, IPad app, connection to SQL Azure (for Access Web App in Sharepoint online), local settings for UK on PC and Ipad, date format dd/mm/yyyy

The date returned to the server from a DatePicker control is consistently one day less than the date entered. So enter, say, April 7th 2016 on the PowerApp Datepicker (either from F5 on the PC or from the app on the IPad), save, look at the SQL AZure record and it has April 6th 2016. Same over a month boundary - enter 1st May, get 30th April.

The card Update setting is valDateOfBirth.SelectedDate. I've tried Text(valDateOfBirth.SelectedDate,"dd/mm/yyyy") as well but the result is the same.

Looks like a bug...??

[Steelman70 · Accepted solution]

Hello, this definitely sounds like an issue of time zones.  You can check this by putting a text box in your PowerApp and displaying the date field without any formatting.  It should show something like this:

As you can see in my example I have a one hour extra, so I don't have issues when chopping off the time.

In your case, I suspect that the date gets saved with a few hours before midnight the previous day, so you get one day less when you only take the date part.

I imagine that the newly available date picker property called DateTimeZone which you can set to either Local or UTC holds at least part of the key to the solution.  I have not tested this, but just noticed it today.  It is not even included in the online specification for the date picker control.  Otherwise you can try to add n hours to the date picked by the date picker before wiriting back to the database.

In any case please let me know how you get on.

[JonathanGibbs]

Yes, you're right! I changed the subtype of the date field within the Access Web App to DateTime instead of Date, and saw that what it was getting back from PowerApp was 06 April 2016 23:00. Of course, it's taking an hour off for Daylight Saving Time (British Summer Time at the moment). Stupid me.

Changed the DateTimeZone property of the Power App DatePicker control to UTC instead of Local, and the correct 07 April 2016 00:00 comes through to the server.

Thanks!

[Steelman70]

You are welcome.

Given that you are also in Europe, you may want to support this idea:

https://powerusers.microsoft.com/t5/PowerApps-Ideas/Date-picker-option-to-start-week-on-a-Monday/idi...

Also, if you use Access Web Apps this might be one for you too:

https://powerusers.microsoft.com/t5/PowerApps-Ideas/PowerApps-must-also-see-SQL-Azure-Queries-not-on...

[jeffgeno]

This isn't actually solved and it's still a bug.

Set the date and time picker to UTC. Use the Collect function to send the date to a SharePoint list.

Select Today - Date comes through as today, 12:00am

Select Tomorrow - Date comes through as tomorrow, 12:00am

Select Yesterday - Date comes through as NOW, today at the current time

Select the Day Before Yesterday - Date comes through as the day before yesterday, 12:00am

So there's clearly some bug sending yesterday's date to SharePoint.

[hpkeong]

Hi

I have reported earlier to PG in private email and it was indeed a bug, and nothing to do with UTC or local time setting. If things needs further settingm, then Microsot will be in big trouble.

PG has tested together with me that:

1. When using Create App from Data, the Datepicker will show correct Date

2. If Datepicker is created manually, the date will be different by one day if the Properties of the Date in the CDM entity is Date.

So, temporary measure is DON;T use Date properties but instead, use TEXT, and create our own DatePicker and AL are solved (while awaiting bug fixing).

My ideas:

- If things need furhter elaboration or special setting, then it is better report to PG as it is definitely a bug.

Sharing with gratiture.

[jeffgeno]

Thanks for the suggestion. I can confirm that setting the SharePoint list column to a single line of text rather than date and time works correctly. That's going to cause problems on the SharePoint side of things, but since the list will mostly be analyzed in Excel, we can mostly work around it. This should work properly with the right data types.

[CarlosFigueira]

There was a bug in sending dates to the connectors that was fixed in the latest release (2.0.500). I tried a simple scenario: sending dates to sharepoint, both via the App From Data and directly with the Collect function (while retrieving the date from DatePicker.SelectedDate), and the date was saved correctly in the SP list.

Could you try your scenario again with the new release to see whether you still see the problem? Thanks!

[hpkeong]

Hi Carlos:

Sorry for late reply to test it out.

Yes, the bugs is finally cleared. Thanks.

Just curious - apart from: Text, Integer, Number, which I can see the protection on Entry by user, I don;t see the use of Date properties if I am creating my apps without using Display Form or Edit Form. Maybe most of the time I am writing from scratch.

Anyway, thanks a have a nice day.

[jeffgeno]

I can also confirm that this is resolved. Thanks!