UWP: Confusing time behavior when setting dates about data-collection-dotnet HOT 8 CLOSED

@mikewilburn How do you think this should work?

Would it be reasonable to say that all dates are at midnight UTC for the selected date? Midnight local time for the selected date?

Should we expose a date and a time field for every date?

It seems like the concept of a time doesn't really make sense for something like a tree being planted, whereas it may make sense for a tree inspection. How can we get this behavior right for Trees of Portland while keeping the app generic?

from data-collection-dotnet.

Would it be reasonable to say that all dates are at midnight UTC for the selected date? Midnight local time for the selected date?

I think midnight local time seems reasonable.
I guess something to consider is whether the time is merely entered/displayed in local time but actually stored in UTC. Is this presently the case?

Should we expose a date and a time field for every date?

I think there was a conscious decision to the drop the time component of date fields in the app (Planted_Date & Collected_Date) since this granularity didn't feel necessary.
As for a tree inspection, you're right - a user may want this. However, the nice thing is that this can be set in the web map via the layer's pop-up configuration dialog:

from data-collection-dotnet.

@mikewilburn Yes, the dates are always stored UTC. And really everything is correct, the only issue is the formatted string produced by the popup manager is always in UTC, but doesn't say that.

The app is always showing the formatted value from the popup manager, but I wonder if we need to do some extra work to format the dates manually? Perhaps in a user-configurable way - show UTC, local, or both..

from data-collection-dotnet.

If we ensure that a user is entering datetimes in local time, and that we display them also in local time, does this then solve that?
I think it'd be pretty unlikely for a user in a typical collection scenario to want to show datetimes in UTC, unless they're doing some simultaneous, truly global stuff. My suggestion would be that we don't need to invest the time to make date & time display configurable.

In my mind, the solution here would be to retrieve the date from the popup manager, and then format and display in local time. What do you think?

from data-collection-dotnet.

Proposed solution:

• Instead of using PopupFieldValue.FormattedValue directly, create a Converter taking PopupFieldValue
  • if PopupFieldValue.OriginalValue is date time, format manually
  • otherwise, return PopupFieldValue.FormattedValue

This should take about a day to implement and test.

from data-collection-dotnet.

@nCastle1 can you explain under what circumstances you think it is using the current time and associating that with the date/time value that is stored?

Assuming an offset of 8 hours between West Coast time and UTC, I have so far not been able to reproduce this behavior by setting the value to the current day.

from data-collection-dotnet.

Some observations I wanted to capture so we're aware of what this behavior is --

Note:

When capturing a date in UWP, it uses the specified date and the current time.
When capturing a date in WPF, it uses the specified date and 12:00 AM.

True for both platforms:

Once a date has been captured with a time, updating the date will continue to re-use the initially-specified time.

from data-collection-dotnet.

When testing this after 4pm PST (midnight UTC), the date that is set for a record remains consistent after the record is saved, de-selected, and re-selected.

In previous behavior (and as shown in the description gif), date/time was set according to the local time. When saved, this was interpreted as UTC time. This means when re-identifying the feature, the UTC time was displayed back in local time, meaning 8 hours (for UTC --> PST) was subtracted from the date/time and thus the date was often rewinded by a day. This was only observed for date/time fields whose date was captured after 4pm.

from data-collection-dotnet.