Ignore timezone for time widget

Ideas
1

Currently, times from the time widget are saved and displayed with timezones. This means that if a user fills out a form in one timezone, saves it, and then reopens it in another timezone (or just changes the timezone on their phone), the date will be shown differently.

In particular, this results in bad behavior around daylight savings time changes. See this Collect bug report for details.

The proposed way to address this is for Collect to display the time as initially selected for the time widget, completely ignoring the timezone. This would mean that if the user selected 1:00 PM, the time for that field would always be displayed as 1:00 PM no matter what timezone the device was set to.

The timezone would still be sent with the form data and it would be up to analysis tools to decide how to use it (this is the current behavior).

With the proposed changes to the Time widget, if a user captured the time 3:30pm in Nairobi (UTC+03:00) and then traveled to London (UTC+1:00 in June because of daylight savings time) and reopened the form, s/he would see the time as 3:30pm. The time would be stored and sent as 15:30:00.000+03.

The DateTime widget would still display the time based on the local timezone. For example, if a user captured the time 3:30pm on 6/7/2017 in Nairobi (UTC+03:00) and then traveled to London (UTC+1:00 in June because of daylight savings time) and reopened the form, s/he would now see the time as 1:30pm. The datetime would be stored and sent as 2017-06-07T15:30:00.000+03.

If you are against this change, please describe why. If you are for it, please click on the blue button to the left of the topic title to vote. If there are no major objections, this change will be in the June release.

2

I'm not against this change, but I'm worried that the difference between Time and DateTime widget's behavior around time zones is subtle and might confuse form designers and data managers.

3

Because of daylight savings time, a time without a date can't consistently be interpreted. The current behavior is that the time from a time widget is implicitly matched with the date January 1st, 1970. That's why users are seeing dates that are as expected during the winter and then dates that change by one hour each time the form is opened in the summer.

With DateTime, the time can be interpreted along with the date when it was captured so the time is at least consistent within one location. That said, I think there's also a case to be made for ignoring timezone when it comes to displaying time from DateTime widgets.

4

This uncovered a lot of interesting information and areas for possible future improvements.

In the end, we decided not to continue including timezone for backwards compatibility but to interpret the time with the current date. This means that times within Collect are now consistent when accessed within the same daylight savings time period. However, they will still be off when accessed across daylight savings changes.

For example, if I fill a form during summer time and then reopen it 3 months later still in summer time, any time fields in the form will still show the same time. However, if I fill a form during summer time and then reopen it two days later in winter time, any time fields will show a time that is off by the daylight savings time change amount.