Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
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
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
Original issue reported on code.google.com by
yanokwa
on 27 Jul 2011 at 6:56