add timezone support about collect HOT 7 CLOSED

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

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.

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.

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.

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 

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

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>