Any updates on this 4 months later?
Worried that if I create a work-around, it might be fixed and then my work-around will be pulling the incorrect dates, given PowerApps won't be doubling the times anymore.
This seems to be working. Can you provide more detail if you still have any problem.
Here is an example where we have a DatePicker and a label showing formatted value for DataPicker1.SelectedDate
As it is shown in the Label control the time is set to midnight for the selected date.
The issue arises when you store data into an on-premise server. The date card picker shows the correct time, however after you enter your first case, all subsequent cases will have the time being double that what it is supposed to be.
Date Picker - 07:00
First record stored - 07:00
Second record stored - 14:00
Related thread : https://powerusers.microsoft.com/t5/General-Discussion/Now-Bug-in-Online-Developer/m-p/176941#M58674
Can setting the DatePicker's DateTimeZone property to UTC help solve this issue?
If not, could you please open a support call, so that we understand this and reproduce it?
I thought the text and video were enough to reproduce it but sure, if you PM me I can share an export of the app and go through it with you?
I am still searching, but I am not sure that there are any unknown bugs here. This still looks like a time zone problem to me.
Note that PowerApps by default shows dates in the browser's local time. Meanwhile SharePoint by default shows dates in server's time zone. This results in a potentially confusing situation, where the same browser window in SharePoint that is using a PowerApps form shows dates in two different time zones.
In PowerApps, DatePicker.SelectedDate always zeroes out the time to midnight. However, which midnight it uses depends on DatePicker.DateTimeZone property. By default, it is Local, so it sets the time to browser's midnight. If DateTimeZone property is changed to UTC, the DatePicker then sets the time to UTC midnight. In these situations it is possible to have Text(DatePicker.SelectedDate) show non-midnight time, because it is showing UTC midnight in local time.
Finally: there is one known bug, which I am fixing now. In some cases, it is possible for DatePicker to show the incorrect date. This happens only to DatePickers in UTC mode that are initialized to particular DefaultDate values that fall on one date in UTC, but a different date in browser time zone - and then only on initial load, not in the much more common scenario of the DefaultDate being assigned after an event. It doesn't look like this bug is in effect here.
Fill out a quick form to claim your user group badge now!
Find out where you can attend!
Features releasing from October 2019 through March 2020
Learn how to build the business apps that you need.