add timezone support

[mitchellsundt]

Migrated to getodk/collect#39 by spacetelescope/github-issues-import

Originally reported on Google Code with ID 272

in collect's time/date widgets, change the code to stop writing our custom strings,
but instead writing a iso8601 string. yyyy-mm-ddTHH:MM:SSZ±hh:mm seems reasonable.
to support partial datetime (in case someone wants just a date as a default value and
for backwards compatibility), might be worth it to look at http://joda-time.sourceforge.net/index.html
to do the parsing.

i have no idea how datetime is done in aggregate, so i'll leave that to mitch. the
problem i see there is that aggregate exports to different systems so lots of bad things
might happen... 

Reported by yanokwa on 2011-07-27 06:56:22

[mitchellsundt]

Migrated to opendatakit/collect#39 (comment) by spacetelescope/github-issues-import

http://stackoverflow.com/questions/2532729/daylight-saving-time-and-timezone-best-practices/3269325
has lots of ideas as well.

Reported by yanokwa on 2011-07-27 07:04:19

[mitchellsundt]

Migrated to opendatakit/collect#39 (comment) by spacetelescope/github-issues-import

did some more digging...

time is currently stored in jr as a gmt timestamp (might be utc, so worth checking
that out). to make this work well, you'll need to change the timedata data structure
to include the offset (hours and minutes), the timezone name, and the utc timestamp
of when the timezone was generated. this extra data is needed because timezones aren't
static and you need to know when in time your timezone was generated.

http://stackoverflow.com/questions/2532729/daylight-saving-time-and-timezone-best-practices/3269325
has a bit more.

Reported by yanokwa on 2011-07-27 07:27:15

[mitchellsundt]

Migrated to opendatakit/collect#39 (comment) by spacetelescope/github-issues-import

My 2 cents... I think we should keep it as simple as possible.

I do agree that writing a custom string is suboptimal so we should think about that.

However, I think that sending around anything but UTC or GMT can be problematic and
should be avoided. It's better to send it through the entire system in a standard interchangeable
format and covert it at the end into the format you want. I think it's fine for users
to create widgets that show in local time and then have it transmit in UTC and let
the end product (which we don't know what that is) covert it to the desired format.

I think there is nice middle ground here but we want to avoid it becoming complex and
when you manage timezones it gets complex fast.

Reported by wbrunette on 2011-07-27 07:56:51

[mitchellsundt]

Migrated to opendatakit/collect#39 (comment) by spacetelescope/github-issues-import

Also, since Java's Date object doesn't retain the timezone (if used consistently, it
should be UTC), it would complicate a bunch of JR, Collect and Aggregate code to pass
a structured object around that tracked time zones. Better to just pass UTC and have
a JR function that retrieves the device's locale and stuff it in a auto-populated field
in the form; then let the back end reconstruct the time zone at time of data capture.

Reported by mitchellsundt on 2011-07-27 16:33:12

[mitchellsundt]

Migrated to opendatakit/collect#39 (comment) by spacetelescope/github-issues-import

agreed with passing around utc (as time in ms) but it seems dangerous not having the
timezone closely associated. 

hate to use strings, but a iso8601 string is pretty standard. yyyy-mm-ddTHH:MM:SSZ±hh:mm
and it's easy to 

Reported by yanokwa on 2011-07-27 18:43:13

[mitchellsundt]

Migrated to opendatakit/collect#39 (comment) by spacetelescope/github-issues-import

Standard strings are fine as long as it's supported everywhere. How does it work in
Fusion Tables for example? 

Reported by wbrunette on 2011-07-27 19:34:01

[mitchellsundt]

Migrated to opendatakit/collect#39 (comment) by spacetelescope/github-issues-import

javarosa (at least in the trunk build of collect) has timezone support. when i record
anything time related, it does save the timezone out to the xml. when i load anything
from a different timezone, it displays the time in my current time zone.

<timeStamp>2011-08-05T20:59:02.899-07</timeStamp>
<dateTime>2009-05-15T00:01:00.000-07</dateTime>
<time>23:00:00.000-07</time>
<date>2010-06-15</date>

Reported by yanokwa on 2011-08-06 04:21:29

• Status changed: Fixed