add timezone support

[GoogleCodeExporter]

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... 

Original issue reported on code.google.com by yanokwa on 27 Jul 2011 at 6:56

[GoogleCodeExporter]

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

Original comment by yanokwa on 27 Jul 2011 at 7:04

[GoogleCodeExporter]

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-bes
t-practices/3269325 has a bit more.

Original comment by yanokwa on 27 Jul 2011 at 7:27

[GoogleCodeExporter]

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.

Original comment by wbrune...@gmail.com on 27 Jul 2011 at 7:56

[GoogleCodeExporter]

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.

Original comment by mitchellsundt@gmail.com on 27 Jul 2011 at 4:33

[GoogleCodeExporter]

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 

Original comment by yanokwa on 27 Jul 2011 at 6:43

[GoogleCodeExporter]

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

Original comment by wbrune...@gmail.com on 27 Jul 2011 at 7:34

[GoogleCodeExporter]

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>

Original comment by yanokwa on 6 Aug 2011 at 4:21

• Changed state: Fixed