Is there any reason the times stamped are not UTC? It seems this would
be optimal but it seems it's also too late to implement this as it
would be a nightmare for backwards compatibility, no?
So I propose we patch it to include the timezone in the ISO 8601
complaint way, like so:
2011-07-25T10:11:09.320-0400
instead of just
2011-07-25T10:11:09.320
Any objections? I would imagine most code on the receiving end would
deal with this without any modification. A really picky regex parsing
method might have to be tweaked. But at least it will be clear when a
string has timezone, so any without should be treated as local time
(on the phone).
I suppose another option might be to include both versions in a
space-separated string, like
It seems that Clayton Sims added timezone support here about four
months ago. Could it be that the javarosa libs in the odk package are
just out of date?
I compiled up the latest version of javarosa and then compiled it into
ODK and installed it on my device, but I'm getting a wretched
exception and force close when I try to submit a form:
I tried a clean build and still nothing so I don't know what's up
there. But perhaps if someone smarter than me could update the ODK
repository with the latest JavaRosa libs we should get timezones for
free!!!
Thoughts?
···
On 25 July 2011 14:43, Thomas Smyth wrote:
> Is there any reason the times stamped are not UTC? It seems this would
> be optimal but it seems it's also too late to implement this as it
> would be a nightmare for backwards compatibility, no?
>
> So I propose we patch it to include the timezone in the ISO 8601
> complaint way, like so:
>
> 2011-07-25T10:11:09.320-0400
>
> instead of just
>
> 2011-07-25T10:11:09.320
>
> Any objections? I would imagine most code on the receiving end would
> deal with this without any modification. A really picky regex parsing
> method might have to be tweaked. But at least it will be clear when a
> string has timezone, so any without should be treated as local time
> (on the phone).
>
> I suppose another option might be to include both versions in a
> space-separated string, like
>
> 2011-07-25T10:11:09.320 2011-07-25T10:11:09.320-0400
>
> But this seems like it would be just as likely to cause processing errors.
>
> Anyway I can write this patch once we decide on the best way.
>
> Thoughts?
>
···
On 25 July 2011 15:52, Thomas Smyth wrote:
> Upon further inspection I'm seeing that writing the timestamp is
> actually handled in the JavaRosa libraries, right here to be specific:
>
> https://bitbucket.org/javarosa/javarosa/src/522ade3f6e72/core/src/org/javarosa/core/model/utils/DateUtils.java#cl-210
>
> It seems that Clayton Sims added timezone support here about four
> months ago. Could it be that the javarosa libs in the odk package are
> just out of date?
>
> I compiled up the latest version of javarosa and then compiled it into
> ODK and installed it on my device, but I'm getting a wretched
> exception and force close when I try to submit a form:
>
> java.lang.VerifyError:
> org.odk.collect.android.activities.InstanceUploaderActivity
>
> I tried a clean build and still nothing so I don't know what's up
> there. But perhaps if someone smarter than me could update the ODK
> repository with the latest JavaRosa libs we should get timezones for
> free!!!
>
> Thoughts?
>
>
>
> On 25 July 2011 14:43, Thomas Smyth wrote:
>> Is there any reason the times stamped are not UTC? It seems this would
>> be optimal but it seems it's also too late to implement this as it
>> would be a nightmare for backwards compatibility, no?
>>
>> So I propose we patch it to include the timezone in the ISO 8601
>> complaint way, like so:
>>
>> 2011-07-25T10:11:09.320-0400
>>
>> instead of just
>>
>> 2011-07-25T10:11:09.320
>>
>> Any objections? I would imagine most code on the receiving end would
>> deal with this without any modification. A really picky regex parsing
>> method might have to be tweaked. But at least it will be clear when a
>> string has timezone, so any without should be treated as local time
>> (on the phone).
>>
>> I suppose another option might be to include both versions in a
>> space-separated string, like
>>
>> 2011-07-25T10:11:09.320 2011-07-25T10:11:09.320-0400
>>
>> But this seems like it would be just as likely to cause processing errors.
>>
>> Anyway I can write this patch once we decide on the best way.
>>
>> Thoughts?
>>
>
I would also patch my project with your modifications regarding Timezone.
As a beginner in ODK Collect code, I couldn't say if this is OK or not, but
give it a try..
It seems that Clayton Sims added timezone support here about four
months ago. Could it be that the javarosa libs in the odk package are
just out of date?
I compiled up the latest version of javarosa and then compiled it into
ODK and installed it on my device, but I'm getting a wretched
exception and force close when I try to submit a form:
I tried a clean build and still nothing so I don't know what's up
there. But perhaps if someone smarter than me could update the ODK
repository with the latest JavaRosa libs we should get timezones for
free!!!
Is there any reason the times stamped are not UTC? It seems this would
be optimal but it seems it's also too late to implement this as it
would be a nightmare for backwards compatibility, no?
So I propose we patch it to include the timezone in the ISO 8601
complaint way, like so:
2011-07-25T10:11:09.320-0400
instead of just
2011-07-25T10:11:09.320
Any objections? I would imagine most code on the receiving end would
deal with this without any modification. A really picky regex parsing
method might have to be tweaked. But at least it will be clear when a
string has timezone, so any without should be treated as local time
(on the phone).
I suppose another option might be to include both versions in a
space-separated string, like
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.
in collect's time/date widgets, you'll need to change the code to stop
writing custom strings, but instead write 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. pretty sure you'll have to change some code so you can
support the new timedata additions. then you'll also have to decide
exactly what time aggregate will export to other systems (fusion
tables, spreadsheets, etc).
···
On Tue, Jul 26, 2011 at 13:02, Thales A. Ceolin wrote:
> I would also patch my project with your modifications regarding Timezone.
> As a beginner in ODK Collect code, I couldn't say if this is OK or not, but
> give it a try..
> I think you could open an issue as Enhancement
> at http://code.google.com/p/opendatakit/issues/ and the project owners would
> evaluate...
>
> --
> Thales A. Ceolin
>
>
> On Tue, Jul 26, 2011 at 4:51 PM, Thomas Smyth wrote:
>>
>> Anyone?
>>
>> On 25 July 2011 15:52, Thomas Smyth wrote:
>> > Upon further inspection I'm seeing that writing the timestamp is
>> > actually handled in the JavaRosa libraries, right here to be specific:
>> >
>> >
>> > https://bitbucket.org/javarosa/javarosa/src/522ade3f6e72/core/src/org/javarosa/core/model/utils/DateUtils.java#cl-210
>> >
>> > It seems that Clayton Sims added timezone support here about four
>> > months ago. Could it be that the javarosa libs in the odk package are
>> > just out of date?
>> >
>> > I compiled up the latest version of javarosa and then compiled it into
>> > ODK and installed it on my device, but I'm getting a wretched
>> > exception and force close when I try to submit a form:
>> >
>> > java.lang.VerifyError:
>> > org.odk.collect.android.activities.InstanceUploaderActivity
>> >
>> > I tried a clean build and still nothing so I don't know what's up
>> > there. But perhaps if someone smarter than me could update the ODK
>> > repository with the latest JavaRosa libs we should get timezones for
>> > free!!!
>> >
>> > Thoughts?
>> >
>> >
>> >
>> > On 25 July 2011 14:43, Thomas Smyth wrote:
>> >> Is there any reason the times stamped are not UTC? It seems this would
>> >> be optimal but it seems it's also too late to implement this as it
>> >> would be a nightmare for backwards compatibility, no?
>> >>
>> >> So I propose we patch it to include the timezone in the ISO 8601
>> >> complaint way, like so:
>> >>
>> >> 2011-07-25T10:11:09.320-0400
>> >>
>> >> instead of just
>> >>
>> >> 2011-07-25T10:11:09.320
>> >>
>> >> Any objections? I would imagine most code on the receiving end would
>> >> deal with this without any modification. A really picky regex parsing
>> >> method might have to be tweaked. But at least it will be clear when a
>> >> string has timezone, so any without should be treated as local time
>> >> (on the phone).
>> >>
>> >> I suppose another option might be to include both versions in a
>> >> space-separated string, like
>> >>
>> >> 2011-07-25T10:11:09.320 2011-07-25T10:11:09.320-0400
>> >>
>> >> But this seems like it would be just as likely to cause processing
>> >> errors.
>> >>
>> >> Anyway I can write this patch once we decide on the best way.
>> >>
>> >> Thoughts?
>> >>
>> >
>
>
Hmm, okay I'll take a look. By the way, I think the 'Z' should only be
there if it's UTC. If not, replace the Z with +-XXXX or +-hh:mm
If I patch this, I think it will only be Collect, since I have my own
aggregator. Would you still be interested in that?
···
On 27 July 2011 03:28, Yaw Anokwa wrote:
> tom,
>
> the instance uploader bug was reported by sam at
> http://code.google.com/p/opendatakit/issues/detail?id=270. that's a
> bug that only occurs in android 1.5/1.6 and it's been fixed in trunk.
>
>
> time is hard.
>
> 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.
>
> in collect's time/date widgets, you'll need to change the code to stop
> writing custom strings, but instead write 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. pretty sure you'll have to change some code so you can
> support the new timedata additions. then you'll also have to decide
> exactly what time aggregate will export to other systems (fusion
> tables, spreadsheets, etc).
>
> anyway, the bug has been filed at
> http://code.google.com/p/opendatakit/issues/detail?id=272. if you can
> get a patch in, we'd certainly appreciate it.
>
> yaw
>
> On Tue, Jul 26, 2011 at 13:02, Thales A. Ceolin wrote:
>> I would also patch my project with your modifications regarding Timezone.
>> As a beginner in ODK Collect code, I couldn't say if this is OK or not, but
>> give it a try..
>> I think you could open an issue as Enhancement
>> at http://code.google.com/p/opendatakit/issues/ and the project owners would
>> evaluate...
>>
>> --
>> Thales A. Ceolin
>>
>>
>> On Tue, Jul 26, 2011 at 4:51 PM, Thomas Smyth wrote:
>>>
>>> Anyone?
>>>
>>> On 25 July 2011 15:52, Thomas Smyth wrote:
>>> > Upon further inspection I'm seeing that writing the timestamp is
>>> > actually handled in the JavaRosa libraries, right here to be specific:
>>> >
>>> >
>>> > https://bitbucket.org/javarosa/javarosa/src/522ade3f6e72/core/src/org/javarosa/core/model/utils/DateUtils.java#cl-210
>>> >
>>> > It seems that Clayton Sims added timezone support here about four
>>> > months ago. Could it be that the javarosa libs in the odk package are
>>> > just out of date?
>>> >
>>> > I compiled up the latest version of javarosa and then compiled it into
>>> > ODK and installed it on my device, but I'm getting a wretched
>>> > exception and force close when I try to submit a form:
>>> >
>>> > java.lang.VerifyError:
>>> > org.odk.collect.android.activities.InstanceUploaderActivity
>>> >
>>> > I tried a clean build and still nothing so I don't know what's up
>>> > there. But perhaps if someone smarter than me could update the ODK
>>> > repository with the latest JavaRosa libs we should get timezones for
>>> > free!!!
>>> >
>>> > Thoughts?
>>> >
>>> >
>>> >
>>> > On 25 July 2011 14:43, Thomas Smyth wrote:
>>> >> Is there any reason the times stamped are not UTC? It seems this would
>>> >> be optimal but it seems it's also too late to implement this as it
>>> >> would be a nightmare for backwards compatibility, no?
>>> >>
>>> >> So I propose we patch it to include the timezone in the ISO 8601
>>> >> complaint way, like so:
>>> >>
>>> >> 2011-07-25T10:11:09.320-0400
>>> >>
>>> >> instead of just
>>> >>
>>> >> 2011-07-25T10:11:09.320
>>> >>
>>> >> Any objections? I would imagine most code on the receiving end would
>>> >> deal with this without any modification. A really picky regex parsing
>>> >> method might have to be tweaked. But at least it will be clear when a
>>> >> string has timezone, so any without should be treated as local time
>>> >> (on the phone).
>>> >>
>>> >> I suppose another option might be to include both versions in a
>>> >> space-separated string, like
>>> >>
>>> >> 2011-07-25T10:11:09.320 2011-07-25T10:11:09.320-0400
>>> >>
>>> >> But this seems like it would be just as likely to cause processing
>>> >> errors.
>>> >>
>>> >> Anyway I can write this patch once we decide on the best way.
>>> >>
>>> >> Thoughts?
>>> >>
>>> >
>>
>>
>
yup, still interested. and yeah, you are correct about the z...
···
On Wed, Jul 27, 2011 at 05:26, Thomas Smyth wrote:
> Hmm, okay I'll take a look. By the way, I think the 'Z' should only be
> there if it's UTC. If not, replace the Z with +-XXXX or +-hh:mm
>
> If I patch this, I think it will only be Collect, since I have my own
> aggregator. Would you still be interested in that?
>
> On 27 July 2011 03:28, Yaw Anokwa wrote:
>> tom,
>>
>> the instance uploader bug was reported by sam at
>> http://code.google.com/p/opendatakit/issues/detail?id=270. that's a
>> bug that only occurs in android 1.5/1.6 and it's been fixed in trunk.
>>
>>
>> time is hard.
>>
>> 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.
>>
>> in collect's time/date widgets, you'll need to change the code to stop
>> writing custom strings, but instead write 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. pretty sure you'll have to change some code so you can
>> support the new timedata additions. then you'll also have to decide
>> exactly what time aggregate will export to other systems (fusion
>> tables, spreadsheets, etc).
>>
>> anyway, the bug has been filed at
>> http://code.google.com/p/opendatakit/issues/detail?id=272. if you can
>> get a patch in, we'd certainly appreciate it.
>>
>> yaw
>>
>> On Tue, Jul 26, 2011 at 13:02, Thales A. Ceolin wrote:
>>> I would also patch my project with your modifications regarding Timezone.
>>> As a beginner in ODK Collect code, I couldn't say if this is OK or not, but
>>> give it a try..
>>> I think you could open an issue as Enhancement
>>> at http://code.google.com/p/opendatakit/issues/ and the project owners would
>>> evaluate...
>>>
>>> --
>>> Thales A. Ceolin
>>>
>>>
>>> On Tue, Jul 26, 2011 at 4:51 PM, Thomas Smyth wrote:
>>>>
>>>> Anyone?
>>>>
>>>> On 25 July 2011 15:52, Thomas Smyth wrote:
>>>> > Upon further inspection I'm seeing that writing the timestamp is
>>>> > actually handled in the JavaRosa libraries, right here to be specific:
>>>> >
>>>> >
>>>> > https://bitbucket.org/javarosa/javarosa/src/522ade3f6e72/core/src/org/javarosa/core/model/utils/DateUtils.java#cl-210
>>>> >
>>>> > It seems that Clayton Sims added timezone support here about four
>>>> > months ago. Could it be that the javarosa libs in the odk package are
>>>> > just out of date?
>>>> >
>>>> > I compiled up the latest version of javarosa and then compiled it into
>>>> > ODK and installed it on my device, but I'm getting a wretched
>>>> > exception and force close when I try to submit a form:
>>>> >
>>>> > java.lang.VerifyError:
>>>> > org.odk.collect.android.activities.InstanceUploaderActivity
>>>> >
>>>> > I tried a clean build and still nothing so I don't know what's up
>>>> > there. But perhaps if someone smarter than me could update the ODK
>>>> > repository with the latest JavaRosa libs we should get timezones for
>>>> > free!!!
>>>> >
>>>> > Thoughts?
>>>> >
>>>> >
>>>> >
>>>> > On 25 July 2011 14:43, Thomas Smyth wrote:
>>>> >> Is there any reason the times stamped are not UTC? It seems this would
>>>> >> be optimal but it seems it's also too late to implement this as it
>>>> >> would be a nightmare for backwards compatibility, no?
>>>> >>
>>>> >> So I propose we patch it to include the timezone in the ISO 8601
>>>> >> complaint way, like so:
>>>> >>
>>>> >> 2011-07-25T10:11:09.320-0400
>>>> >>
>>>> >> instead of just
>>>> >>
>>>> >> 2011-07-25T10:11:09.320
>>>> >>
>>>> >> Any objections? I would imagine most code on the receiving end would
>>>> >> deal with this without any modification. A really picky regex parsing
>>>> >> method might have to be tweaked. But at least it will be clear when a
>>>> >> string has timezone, so any without should be treated as local time
>>>> >> (on the phone).
>>>> >>
>>>> >> I suppose another option might be to include both versions in a
>>>> >> space-separated string, like
>>>> >>
>>>> >> 2011-07-25T10:11:09.320 2011-07-25T10:11:09.320-0400
>>>> >>
>>>> >> But this seems like it would be just as likely to cause processing
>>>> >> errors.
>>>> >>
>>>> >> Anyway I can write this patch once we decide on the best way.
>>>> >>
>>>> >> Thoughts?
>>>> >>
>>>> >
>>>
>>>
>>
>
took a closer look. javarosa (at least in the trunk build of collect)
has time zone support. when i record anything time related, it does
save the time zone out to the xml. when i load anything from a
different timezone, it displays the time in my current time zone.
···
On Wed, Jul 27, 2011 at 12:04, Yaw Anokwa wrote:
> yup, still interested. and yeah, you are correct about the z...
>
> On Wed, Jul 27, 2011 at 05:26, Thomas Smyth wrote:
>> Hmm, okay I'll take a look. By the way, I think the 'Z' should only be
>> there if it's UTC. If not, replace the Z with +-XXXX or +-hh:mm
>>
>> If I patch this, I think it will only be Collect, since I have my own
>> aggregator. Would you still be interested in that?
>>
>> On 27 July 2011 03:28, Yaw Anokwa wrote:
>>> tom,
>>>
>>> the instance uploader bug was reported by sam at
>>> http://code.google.com/p/opendatakit/issues/detail?id=270. that's a
>>> bug that only occurs in android 1.5/1.6 and it's been fixed in trunk.
>>>
>>>
>>> time is hard.
>>>
>>> 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.
>>>
>>> in collect's time/date widgets, you'll need to change the code to stop
>>> writing custom strings, but instead write 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. pretty sure you'll have to change some code so you can
>>> support the new timedata additions. then you'll also have to decide
>>> exactly what time aggregate will export to other systems (fusion
>>> tables, spreadsheets, etc).
>>>
>>> anyway, the bug has been filed at
>>> http://code.google.com/p/opendatakit/issues/detail?id=272. if you can
>>> get a patch in, we'd certainly appreciate it.
>>>
>>> yaw
>>>
>>> On Tue, Jul 26, 2011 at 13:02, Thales A. Ceolin wrote:
>>>> I would also patch my project with your modifications regarding Timezone.
>>>> As a beginner in ODK Collect code, I couldn't say if this is OK or not, but
>>>> give it a try..
>>>> I think you could open an issue as Enhancement
>>>> at http://code.google.com/p/opendatakit/issues/ and the project owners would
>>>> evaluate...
>>>>
>>>> --
>>>> Thales A. Ceolin
>>>>
>>>>
>>>> On Tue, Jul 26, 2011 at 4:51 PM, Thomas Smyth wrote:
>>>>>
>>>>> Anyone?
>>>>>
>>>>> On 25 July 2011 15:52, Thomas Smyth wrote:
>>>>> > Upon further inspection I'm seeing that writing the timestamp is
>>>>> > actually handled in the JavaRosa libraries, right here to be specific:
>>>>> >
>>>>> >
>>>>> > https://bitbucket.org/javarosa/javarosa/src/522ade3f6e72/core/src/org/javarosa/core/model/utils/DateUtils.java#cl-210
>>>>> >
>>>>> > It seems that Clayton Sims added timezone support here about four
>>>>> > months ago. Could it be that the javarosa libs in the odk package are
>>>>> > just out of date?
>>>>> >
>>>>> > I compiled up the latest version of javarosa and then compiled it into
>>>>> > ODK and installed it on my device, but I'm getting a wretched
>>>>> > exception and force close when I try to submit a form:
>>>>> >
>>>>> > java.lang.VerifyError:
>>>>> > org.odk.collect.android.activities.InstanceUploaderActivity
>>>>> >
>>>>> > I tried a clean build and still nothing so I don't know what's up
>>>>> > there. But perhaps if someone smarter than me could update the ODK
>>>>> > repository with the latest JavaRosa libs we should get timezones for
>>>>> > free!!!
>>>>> >
>>>>> > Thoughts?
>>>>> >
>>>>> >
>>>>> >
>>>>> > On 25 July 2011 14:43, Thomas Smyth wrote:
>>>>> >> Is there any reason the times stamped are not UTC? It seems this would
>>>>> >> be optimal but it seems it's also too late to implement this as it
>>>>> >> would be a nightmare for backwards compatibility, no?
>>>>> >>
>>>>> >> So I propose we patch it to include the timezone in the ISO 8601
>>>>> >> complaint way, like so:
>>>>> >>
>>>>> >> 2011-07-25T10:11:09.320-0400
>>>>> >>
>>>>> >> instead of just
>>>>> >>
>>>>> >> 2011-07-25T10:11:09.320
>>>>> >>
>>>>> >> Any objections? I would imagine most code on the receiving end would
>>>>> >> deal with this without any modification. A really picky regex parsing
>>>>> >> method might have to be tweaked. But at least it will be clear when a
>>>>> >> string has timezone, so any without should be treated as local time
>>>>> >> (on the phone).
>>>>> >>
>>>>> >> I suppose another option might be to include both versions in a
>>>>> >> space-separated string, like
>>>>> >>
>>>>> >> 2011-07-25T10:11:09.320 2011-07-25T10:11:09.320-0400
>>>>> >>
>>>>> >> But this seems like it would be just as likely to cause processing
>>>>> >> errors.
>>>>> >>
>>>>> >> Anyway I can write this patch once we decide on the best way.
>>>>> >>
>>>>> >> Thoughts?
>>>>> >>
>>>>> >
>>>>
>>>>
>>>
>>
>
Hmm.. I'll have to check this out again. Good news I think. What
happens if you do a 1/2 hour timezone I wonder? I'll check it out.
···
On 6 August 2011 00:23, Yaw Anokwa wrote:
> took a closer look. javarosa (at least in the trunk build of collect)
> has time zone support. when i record anything time related, it does
> save the time zone out to the xml. when i load anything from a
> different timezone, it displays the time in my current time zone.
>
> 2011-08-05T20:59:02.899-07
> 2009-05-15T00:01:00.000-07
> 23:00:00.000-07
> 2010-06-15
>
>
> On Wed, Jul 27, 2011 at 12:04, Yaw Anokwa wrote:
>> yup, still interested. and yeah, you are correct about the z...
>>
>> On Wed, Jul 27, 2011 at 05:26, Thomas Smyth wrote:
>>> Hmm, okay I'll take a look. By the way, I think the 'Z' should only be
>>> there if it's UTC. If not, replace the Z with +-XXXX or +-hh:mm
>>>
>>> If I patch this, I think it will only be Collect, since I have my own
>>> aggregator. Would you still be interested in that?
>>>
>>> On 27 July 2011 03:28, Yaw Anokwa wrote:
>>>> tom,
>>>>
>>>> the instance uploader bug was reported by sam at
>>>> http://code.google.com/p/opendatakit/issues/detail?id=270. that's a
>>>> bug that only occurs in android 1.5/1.6 and it's been fixed in trunk.
>>>>
>>>>
>>>> time is hard.
>>>>
>>>> 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.
>>>>
>>>> in collect's time/date widgets, you'll need to change the code to stop
>>>> writing custom strings, but instead write 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. pretty sure you'll have to change some code so you can
>>>> support the new timedata additions. then you'll also have to decide
>>>> exactly what time aggregate will export to other systems (fusion
>>>> tables, spreadsheets, etc).
>>>>
>>>> anyway, the bug has been filed at
>>>> http://code.google.com/p/opendatakit/issues/detail?id=272. if you can
>>>> get a patch in, we'd certainly appreciate it.
>>>>
>>>> yaw
>>>>
>>>> On Tue, Jul 26, 2011 at 13:02, Thales A. Ceolin wrote:
>>>>> I would also patch my project with your modifications regarding Timezone.
>>>>> As a beginner in ODK Collect code, I couldn't say if this is OK or not, but
>>>>> give it a try..
>>>>> I think you could open an issue as Enhancement
>>>>> at http://code.google.com/p/opendatakit/issues/ and the project owners would
>>>>> evaluate...
>>>>>
>>>>> --
>>>>> Thales A. Ceolin
>>>>>
>>>>>
>>>>> On Tue, Jul 26, 2011 at 4:51 PM, Thomas Smyth wrote:
>>>>>>
>>>>>> Anyone?
>>>>>>
>>>>>> On 25 July 2011 15:52, Thomas Smyth wrote:
>>>>>> > Upon further inspection I'm seeing that writing the timestamp is
>>>>>> > actually handled in the JavaRosa libraries, right here to be specific:
>>>>>> >
>>>>>> >
>>>>>> > https://bitbucket.org/javarosa/javarosa/src/522ade3f6e72/core/src/org/javarosa/core/model/utils/DateUtils.java#cl-210
>>>>>> >
>>>>>> > It seems that Clayton Sims added timezone support here about four
>>>>>> > months ago. Could it be that the javarosa libs in the odk package are
>>>>>> > just out of date?
>>>>>> >
>>>>>> > I compiled up the latest version of javarosa and then compiled it into
>>>>>> > ODK and installed it on my device, but I'm getting a wretched
>>>>>> > exception and force close when I try to submit a form:
>>>>>> >
>>>>>> > java.lang.VerifyError:
>>>>>> > org.odk.collect.android.activities.InstanceUploaderActivity
>>>>>> >
>>>>>> > I tried a clean build and still nothing so I don't know what's up
>>>>>> > there. But perhaps if someone smarter than me could update the ODK
>>>>>> > repository with the latest JavaRosa libs we should get timezones for
>>>>>> > free!!!
>>>>>> >
>>>>>> > Thoughts?
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On 25 July 2011 14:43, Thomas Smyth wrote:
>>>>>> >> Is there any reason the times stamped are not UTC? It seems this would
>>>>>> >> be optimal but it seems it's also too late to implement this as it
>>>>>> >> would be a nightmare for backwards compatibility, no?
>>>>>> >>
>>>>>> >> So I propose we patch it to include the timezone in the ISO 8601
>>>>>> >> complaint way, like so:
>>>>>> >>
>>>>>> >> 2011-07-25T10:11:09.320-0400
>>>>>> >>
>>>>>> >> instead of just
>>>>>> >>
>>>>>> >> 2011-07-25T10:11:09.320
>>>>>> >>
>>>>>> >> Any objections? I would imagine most code on the receiving end would
>>>>>> >> deal with this without any modification. A really picky regex parsing
>>>>>> >> method might have to be tweaked. But at least it will be clear when a
>>>>>> >> string has timezone, so any without should be treated as local time
>>>>>> >> (on the phone).
>>>>>> >>
>>>>>> >> I suppose another option might be to include both versions in a
>>>>>> >> space-separated string, like
>>>>>> >>
>>>>>> >> 2011-07-25T10:11:09.320 2011-07-25T10:11:09.320-0400
>>>>>> >>
>>>>>> >> But this seems like it would be just as likely to cause processing
>>>>>> >> errors.
>>>>>> >>
>>>>>> >> Anyway I can write this patch once we decide on the best way.
>>>>>> >>
>>>>>> >> Thoughts?
>>>>>> >>
>>>>>> >
>>>>>
>>>>>
>>>>
>>>
>>
>
···
On Mon, Aug 8, 2011 at 06:03, Thomas Smyth wrote:
> Hmm.. I'll have to check this out again. Good news I think. What
> happens if you do a 1/2 hour timezone I wonder? I'll check it out.
>
> On 6 August 2011 00:23, Yaw Anokwa wrote:
>> took a closer look. javarosa (at least in the trunk build of collect)
>> has time zone support. when i record anything time related, it does
>> save the time zone out to the xml. when i load anything from a
>> different timezone, it displays the time in my current time zone.
>>
>> 2011-08-05T20:59:02.899-07
>> 2009-05-15T00:01:00.000-07
>> 23:00:00.000-07
>> 2010-06-15
>>
>>
>> On Wed, Jul 27, 2011 at 12:04, Yaw Anokwa wrote:
>>> yup, still interested. and yeah, you are correct about the z...
>>>
>>> On Wed, Jul 27, 2011 at 05:26, Thomas Smyth wrote:
>>>> Hmm, okay I'll take a look. By the way, I think the 'Z' should only be
>>>> there if it's UTC. If not, replace the Z with +-XXXX or +-hh:mm
>>>>
>>>> If I patch this, I think it will only be Collect, since I have my own
>>>> aggregator. Would you still be interested in that?
>>>>
>>>> On 27 July 2011 03:28, Yaw Anokwa wrote:
>>>>> tom,
>>>>>
>>>>> the instance uploader bug was reported by sam at
>>>>> http://code.google.com/p/opendatakit/issues/detail?id=270. that's a
>>>>> bug that only occurs in android 1.5/1.6 and it's been fixed in trunk.
>>>>>
>>>>>
>>>>> time is hard.
>>>>>
>>>>> 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.
>>>>>
>>>>> in collect's time/date widgets, you'll need to change the code to stop
>>>>> writing custom strings, but instead write 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. pretty sure you'll have to change some code so you can
>>>>> support the new timedata additions. then you'll also have to decide
>>>>> exactly what time aggregate will export to other systems (fusion
>>>>> tables, spreadsheets, etc).
>>>>>
>>>>> anyway, the bug has been filed at
>>>>> http://code.google.com/p/opendatakit/issues/detail?id=272. if you can
>>>>> get a patch in, we'd certainly appreciate it.
>>>>>
>>>>> yaw
>>>>>
>>>>> On Tue, Jul 26, 2011 at 13:02, Thales A. Ceolin wrote:
>>>>>> I would also patch my project with your modifications regarding Timezone.
>>>>>> As a beginner in ODK Collect code, I couldn't say if this is OK or not, but
>>>>>> give it a try..
>>>>>> I think you could open an issue as Enhancement
>>>>>> at http://code.google.com/p/opendatakit/issues/ and the project owners would
>>>>>> evaluate...
>>>>>>
>>>>>> --
>>>>>> Thales A. Ceolin
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 26, 2011 at 4:51 PM, Thomas Smyth wrote:
>>>>>>>
>>>>>>> Anyone?
>>>>>>>
>>>>>>> On 25 July 2011 15:52, Thomas Smyth wrote:
>>>>>>> > Upon further inspection I'm seeing that writing the timestamp is
>>>>>>> > actually handled in the JavaRosa libraries, right here to be specific:
>>>>>>> >
>>>>>>> >
>>>>>>> > https://bitbucket.org/javarosa/javarosa/src/522ade3f6e72/core/src/org/javarosa/core/model/utils/DateUtils.java#cl-210
>>>>>>> >
>>>>>>> > It seems that Clayton Sims added timezone support here about four
>>>>>>> > months ago. Could it be that the javarosa libs in the odk package are
>>>>>>> > just out of date?
>>>>>>> >
>>>>>>> > I compiled up the latest version of javarosa and then compiled it into
>>>>>>> > ODK and installed it on my device, but I'm getting a wretched
>>>>>>> > exception and force close when I try to submit a form:
>>>>>>> >
>>>>>>> > java.lang.VerifyError:
>>>>>>> > org.odk.collect.android.activities.InstanceUploaderActivity
>>>>>>> >
>>>>>>> > I tried a clean build and still nothing so I don't know what's up
>>>>>>> > there. But perhaps if someone smarter than me could update the ODK
>>>>>>> > repository with the latest JavaRosa libs we should get timezones for
>>>>>>> > free!!!
>>>>>>> >
>>>>>>> > Thoughts?
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > On 25 July 2011 14:43, Thomas Smyth wrote:
>>>>>>> >> Is there any reason the times stamped are not UTC? It seems this would
>>>>>>> >> be optimal but it seems it's also too late to implement this as it
>>>>>>> >> would be a nightmare for backwards compatibility, no?
>>>>>>> >>
>>>>>>> >> So I propose we patch it to include the timezone in the ISO 8601
>>>>>>> >> complaint way, like so:
>>>>>>> >>
>>>>>>> >> 2011-07-25T10:11:09.320-0400
>>>>>>> >>
>>>>>>> >> instead of just
>>>>>>> >>
>>>>>>> >> 2011-07-25T10:11:09.320
>>>>>>> >>
>>>>>>> >> Any objections? I would imagine most code on the receiving end would
>>>>>>> >> deal with this without any modification. A really picky regex parsing
>>>>>>> >> method might have to be tweaked. But at least it will be clear when a
>>>>>>> >> string has timezone, so any without should be treated as local time
>>>>>>> >> (on the phone).
>>>>>>> >>
>>>>>>> >> I suppose another option might be to include both versions in a
>>>>>>> >> space-separated string, like
>>>>>>> >>
>>>>>>> >> 2011-07-25T10:11:09.320 2011-07-25T10:11:09.320-0400
>>>>>>> >>
>>>>>>> >> But this seems like it would be just as likely to cause processing
>>>>>>> >> errors.
>>>>>>> >>
>>>>>>> >> Anyway I can write this patch once we decide on the best way.
>>>>>>> >>
>>>>>>> >> Thoughts?
>>>>>>> >>
>>>>>>> >
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
···
On 8 August 2011 10:17, Yaw Anokwa wrote:
> offsets are hhmm, so i assume it will work fine.
>
> On Mon, Aug 8, 2011 at 06:03, Thomas Smyth wrote:
>> Hmm.. I'll have to check this out again. Good news I think. What
>> happens if you do a 1/2 hour timezone I wonder? I'll check it out.
>>
>> On 6 August 2011 00:23, Yaw Anokwa wrote:
>>> took a closer look. javarosa (at least in the trunk build of collect)
>>> has time zone support. when i record anything time related, it does
>>> save the time zone out to the xml. when i load anything from a
>>> different timezone, it displays the time in my current time zone.
>>>
>>> 2011-08-05T20:59:02.899-07
>>> 2009-05-15T00:01:00.000-07
>>> 23:00:00.000-07
>>> 2010-06-15
>>>
>>>
>>> On Wed, Jul 27, 2011 at 12:04, Yaw Anokwa wrote:
>>>> yup, still interested. and yeah, you are correct about the z...
>>>>
>>>> On Wed, Jul 27, 2011 at 05:26, Thomas Smyth wrote:
>>>>> Hmm, okay I'll take a look. By the way, I think the 'Z' should only be
>>>>> there if it's UTC. If not, replace the Z with +-XXXX or +-hh:mm
>>>>>
>>>>> If I patch this, I think it will only be Collect, since I have my own
>>>>> aggregator. Would you still be interested in that?
>>>>>
>>>>> On 27 July 2011 03:28, Yaw Anokwa wrote:
>>>>>> tom,
>>>>>>
>>>>>> the instance uploader bug was reported by sam at
>>>>>> http://code.google.com/p/opendatakit/issues/detail?id=270. that's a
>>>>>> bug that only occurs in android 1.5/1.6 and it's been fixed in trunk.
>>>>>>
>>>>>>
>>>>>> time is hard.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> in collect's time/date widgets, you'll need to change the code to stop
>>>>>> writing custom strings, but instead write 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. pretty sure you'll have to change some code so you can
>>>>>> support the new timedata additions. then you'll also have to decide
>>>>>> exactly what time aggregate will export to other systems (fusion
>>>>>> tables, spreadsheets, etc).
>>>>>>
>>>>>> anyway, the bug has been filed at
>>>>>> http://code.google.com/p/opendatakit/issues/detail?id=272. if you can
>>>>>> get a patch in, we'd certainly appreciate it.
>>>>>>
>>>>>> yaw
>>>>>>
>>>>>> On Tue, Jul 26, 2011 at 13:02, Thales A. Ceolin wrote:
>>>>>>> I would also patch my project with your modifications regarding Timezone.
>>>>>>> As a beginner in ODK Collect code, I couldn't say if this is OK or not, but
>>>>>>> give it a try..
>>>>>>> I think you could open an issue as Enhancement
>>>>>>> at http://code.google.com/p/opendatakit/issues/ and the project owners would
>>>>>>> evaluate...
>>>>>>>
>>>>>>> --
>>>>>>> Thales A. Ceolin
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 26, 2011 at 4:51 PM, Thomas Smyth wrote:
>>>>>>>>
>>>>>>>> Anyone?
>>>>>>>>
>>>>>>>> On 25 July 2011 15:52, Thomas Smyth wrote:
>>>>>>>> > Upon further inspection I'm seeing that writing the timestamp is
>>>>>>>> > actually handled in the JavaRosa libraries, right here to be specific:
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > https://bitbucket.org/javarosa/javarosa/src/522ade3f6e72/core/src/org/javarosa/core/model/utils/DateUtils.java#cl-210
>>>>>>>> >
>>>>>>>> > It seems that Clayton Sims added timezone support here about four
>>>>>>>> > months ago. Could it be that the javarosa libs in the odk package are
>>>>>>>> > just out of date?
>>>>>>>> >
>>>>>>>> > I compiled up the latest version of javarosa and then compiled it into
>>>>>>>> > ODK and installed it on my device, but I'm getting a wretched
>>>>>>>> > exception and force close when I try to submit a form:
>>>>>>>> >
>>>>>>>> > java.lang.VerifyError:
>>>>>>>> > org.odk.collect.android.activities.InstanceUploaderActivity
>>>>>>>> >
>>>>>>>> > I tried a clean build and still nothing so I don't know what's up
>>>>>>>> > there. But perhaps if someone smarter than me could update the ODK
>>>>>>>> > repository with the latest JavaRosa libs we should get timezones for
>>>>>>>> > free!!!
>>>>>>>> >
>>>>>>>> > Thoughts?
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > On 25 July 2011 14:43, Thomas Smyth wrote:
>>>>>>>> >> Is there any reason the times stamped are not UTC? It seems this would
>>>>>>>> >> be optimal but it seems it's also too late to implement this as it
>>>>>>>> >> would be a nightmare for backwards compatibility, no?
>>>>>>>> >>
>>>>>>>> >> So I propose we patch it to include the timezone in the ISO 8601
>>>>>>>> >> complaint way, like so:
>>>>>>>> >>
>>>>>>>> >> 2011-07-25T10:11:09.320-0400
>>>>>>>> >>
>>>>>>>> >> instead of just
>>>>>>>> >>
>>>>>>>> >> 2011-07-25T10:11:09.320
>>>>>>>> >>
>>>>>>>> >> Any objections? I would imagine most code on the receiving end would
>>>>>>>> >> deal with this without any modification. A really picky regex parsing
>>>>>>>> >> method might have to be tweaked. But at least it will be clear when a
>>>>>>>> >> string has timezone, so any without should be treated as local time
>>>>>>>> >> (on the phone).
>>>>>>>> >>
>>>>>>>> >> I suppose another option might be to include both versions in a
>>>>>>>> >> space-separated string, like
>>>>>>>> >>
>>>>>>>> >> 2011-07-25T10:11:09.320 2011-07-25T10:11:09.320-0400
>>>>>>>> >>
>>>>>>>> >> But this seems like it would be just as likely to cause processing
>>>>>>>> >> errors.
>>>>>>>> >>
>>>>>>>> >> Anyway I can write this patch once we decide on the best way.
>>>>>>>> >>
>>>>>>>> >> Thoughts?
>>>>>>>> >>
>>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
I just checked, and with my build of Collect I'm getting this:
2011-10-07T13:42:35.527
No timezone. Can someone else try this with RC2? Note the data is from
a jr:preload timestamp thingy.
I tried doing a clean build and I'm still getting this. When were the
javarosa libraries last updated? I tried downloading the 0.9.6 jar
from the jr website but I got a bunch of build errors. Perhaps we
should include the version number on the jar file filename.
···
On 8 August 2011 10:38, Thomas Smyth wrote:
> Well the ones you just posted were only HH
>
> On 8 August 2011 10:17, Yaw Anokwa wrote:
>> offsets are hhmm, so i assume it will work fine.
>>
>> On Mon, Aug 8, 2011 at 06:03, Thomas Smyth wrote:
>>> Hmm.. I'll have to check this out again. Good news I think. What
>>> happens if you do a 1/2 hour timezone I wonder? I'll check it out.
>>>
>>> On 6 August 2011 00:23, Yaw Anokwa wrote:
>>>> took a closer look. javarosa (at least in the trunk build of collect)
>>>> has time zone support. when i record anything time related, it does
>>>> save the time zone out to the xml. when i load anything from a
>>>> different timezone, it displays the time in my current time zone.
>>>>
>>>> 2011-08-05T20:59:02.899-07
>>>> 2009-05-15T00:01:00.000-07
>>>> 23:00:00.000-07
>>>> 2010-06-15
>>>>
>>>>
>>>> On Wed, Jul 27, 2011 at 12:04, Yaw Anokwa wrote:
>>>>> yup, still interested. and yeah, you are correct about the z...
>>>>>
>>>>> On Wed, Jul 27, 2011 at 05:26, Thomas Smyth wrote:
>>>>>> Hmm, okay I'll take a look. By the way, I think the 'Z' should only be
>>>>>> there if it's UTC. If not, replace the Z with +-XXXX or +-hh:mm
>>>>>>
>>>>>> If I patch this, I think it will only be Collect, since I have my own
>>>>>> aggregator. Would you still be interested in that?
>>>>>>
>>>>>> On 27 July 2011 03:28, Yaw Anokwa wrote:
>>>>>>> tom,
>>>>>>>
>>>>>>> the instance uploader bug was reported by sam at
>>>>>>> http://code.google.com/p/opendatakit/issues/detail?id=270. that's a
>>>>>>> bug that only occurs in android 1.5/1.6 and it's been fixed in trunk.
>>>>>>>
>>>>>>>
>>>>>>> time is hard.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> in collect's time/date widgets, you'll need to change the code to stop
>>>>>>> writing custom strings, but instead write 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. pretty sure you'll have to change some code so you can
>>>>>>> support the new timedata additions. then you'll also have to decide
>>>>>>> exactly what time aggregate will export to other systems (fusion
>>>>>>> tables, spreadsheets, etc).
>>>>>>>
>>>>>>> anyway, the bug has been filed at
>>>>>>> http://code.google.com/p/opendatakit/issues/detail?id=272. if you can
>>>>>>> get a patch in, we'd certainly appreciate it.
>>>>>>>
>>>>>>> yaw
>>>>>>>
>>>>>>> On Tue, Jul 26, 2011 at 13:02, Thales A. Ceolin wrote:
>>>>>>>> I would also patch my project with your modifications regarding Timezone.
>>>>>>>> As a beginner in ODK Collect code, I couldn't say if this is OK or not, but
>>>>>>>> give it a try..
>>>>>>>> I think you could open an issue as Enhancement
>>>>>>>> at http://code.google.com/p/opendatakit/issues/ and the project owners would
>>>>>>>> evaluate...
>>>>>>>>
>>>>>>>> --
>>>>>>>> Thales A. Ceolin
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jul 26, 2011 at 4:51 PM, Thomas Smyth wrote:
>>>>>>>>>
>>>>>>>>> Anyone?
>>>>>>>>>
>>>>>>>>> On 25 July 2011 15:52, Thomas Smyth wrote:
>>>>>>>>> > Upon further inspection I'm seeing that writing the timestamp is
>>>>>>>>> > actually handled in the JavaRosa libraries, right here to be specific:
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > https://bitbucket.org/javarosa/javarosa/src/522ade3f6e72/core/src/org/javarosa/core/model/utils/DateUtils.java#cl-210
>>>>>>>>> >
>>>>>>>>> > It seems that Clayton Sims added timezone support here about four
>>>>>>>>> > months ago. Could it be that the javarosa libs in the odk package are
>>>>>>>>> > just out of date?
>>>>>>>>> >
>>>>>>>>> > I compiled up the latest version of javarosa and then compiled it into
>>>>>>>>> > ODK and installed it on my device, but I'm getting a wretched
>>>>>>>>> > exception and force close when I try to submit a form:
>>>>>>>>> >
>>>>>>>>> > java.lang.VerifyError:
>>>>>>>>> > org.odk.collect.android.activities.InstanceUploaderActivity
>>>>>>>>> >
>>>>>>>>> > I tried a clean build and still nothing so I don't know what's up
>>>>>>>>> > there. But perhaps if someone smarter than me could update the ODK
>>>>>>>>> > repository with the latest JavaRosa libs we should get timezones for
>>>>>>>>> > free!!!
>>>>>>>>> >
>>>>>>>>> > Thoughts?
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > On 25 July 2011 14:43, Thomas Smyth wrote:
>>>>>>>>> >> Is there any reason the times stamped are not UTC? It seems this would
>>>>>>>>> >> be optimal but it seems it's also too late to implement this as it
>>>>>>>>> >> would be a nightmare for backwards compatibility, no?
>>>>>>>>> >>
>>>>>>>>> >> So I propose we patch it to include the timezone in the ISO 8601
>>>>>>>>> >> complaint way, like so:
>>>>>>>>> >>
>>>>>>>>> >> 2011-07-25T10:11:09.320-0400
>>>>>>>>> >>
>>>>>>>>> >> instead of just
>>>>>>>>> >>
>>>>>>>>> >> 2011-07-25T10:11:09.320
>>>>>>>>> >>
>>>>>>>>> >> Any objections? I would imagine most code on the receiving end would
>>>>>>>>> >> deal with this without any modification. A really picky regex parsing
>>>>>>>>> >> method might have to be tweaked. But at least it will be clear when a
>>>>>>>>> >> string has timezone, so any without should be treated as local time
>>>>>>>>> >> (on the phone).
>>>>>>>>> >>
>>>>>>>>> >> I suppose another option might be to include both versions in a
>>>>>>>>> >> space-separated string, like
>>>>>>>>> >>
>>>>>>>>> >> 2011-07-25T10:11:09.320 2011-07-25T10:11:09.320-0400
>>>>>>>>> >>
>>>>>>>>> >> But this seems like it would be just as likely to cause processing
>>>>>>>>> >> errors.
>>>>>>>>> >>
>>>>>>>>> >> Anyway I can write this patch once we decide on the best way.
>>>>>>>>> >>
>>>>>>>>> >> Thoughts?
>>>>>>>>> >>
>>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
···
On Thu, Oct 20, 2011 at 08:40, Thomas Smyth wrote:
> Reviving this old thread...
>
> I just checked, and with my build of Collect I'm getting this:
>
> 2011-10-07T13:42:35.527
>
> No timezone. Can someone else try this with RC2? Note the data is from
> a jr:preload timestamp thingy.
>
> I tried doing a clean build and I'm still getting this. When were the
> javarosa libraries last updated? I tried downloading the 0.9.6 jar
> from the jr website but I got a bunch of build errors. Perhaps we
> should include the version number on the jar file filename.
>
>
> On 8 August 2011 10:38, Thomas Smyth wrote:
>> Well the ones you just posted were only HH
>>
>> On 8 August 2011 10:17, Yaw Anokwa wrote:
>>> offsets are hhmm, so i assume it will work fine.
>>>
>>> On Mon, Aug 8, 2011 at 06:03, Thomas Smyth wrote:
>>>> Hmm.. I'll have to check this out again. Good news I think. What
>>>> happens if you do a 1/2 hour timezone I wonder? I'll check it out.
>>>>
>>>> On 6 August 2011 00:23, Yaw Anokwa wrote:
>>>>> took a closer look. javarosa (at least in the trunk build of collect)
>>>>> has time zone support. when i record anything time related, it does
>>>>> save the time zone out to the xml. when i load anything from a
>>>>> different timezone, it displays the time in my current time zone.
>>>>>
>>>>> 2011-08-05T20:59:02.899-07
>>>>> 2009-05-15T00:01:00.000-07
>>>>> 23:00:00.000-07
>>>>> 2010-06-15
>>>>>
>>>>>
>>>>> On Wed, Jul 27, 2011 at 12:04, Yaw Anokwa wrote:
>>>>>> yup, still interested. and yeah, you are correct about the z...
>>>>>>
>>>>>> On Wed, Jul 27, 2011 at 05:26, Thomas Smyth wrote:
>>>>>>> Hmm, okay I'll take a look. By the way, I think the 'Z' should only be
>>>>>>> there if it's UTC. If not, replace the Z with +-XXXX or +-hh:mm
>>>>>>>
>>>>>>> If I patch this, I think it will only be Collect, since I have my own
>>>>>>> aggregator. Would you still be interested in that?
>>>>>>>
>>>>>>> On 27 July 2011 03:28, Yaw Anokwa wrote:
>>>>>>>> tom,
>>>>>>>>
>>>>>>>> the instance uploader bug was reported by sam at
>>>>>>>> http://code.google.com/p/opendatakit/issues/detail?id=270. that's a
>>>>>>>> bug that only occurs in android 1.5/1.6 and it's been fixed in trunk.
>>>>>>>>
>>>>>>>>
>>>>>>>> time is hard.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> in collect's time/date widgets, you'll need to change the code to stop
>>>>>>>> writing custom strings, but instead write 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. pretty sure you'll have to change some code so you can
>>>>>>>> support the new timedata additions. then you'll also have to decide
>>>>>>>> exactly what time aggregate will export to other systems (fusion
>>>>>>>> tables, spreadsheets, etc).
>>>>>>>>
>>>>>>>> anyway, the bug has been filed at
>>>>>>>> http://code.google.com/p/opendatakit/issues/detail?id=272. if you can
>>>>>>>> get a patch in, we'd certainly appreciate it.
>>>>>>>>
>>>>>>>> yaw
>>>>>>>>
>>>>>>>> On Tue, Jul 26, 2011 at 13:02, Thales A. Ceolin wrote:
>>>>>>>>> I would also patch my project with your modifications regarding Timezone.
>>>>>>>>> As a beginner in ODK Collect code, I couldn't say if this is OK or not, but
>>>>>>>>> give it a try..
>>>>>>>>> I think you could open an issue as Enhancement
>>>>>>>>> at http://code.google.com/p/opendatakit/issues/ and the project owners would
>>>>>>>>> evaluate...
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Thales A. Ceolin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jul 26, 2011 at 4:51 PM, Thomas Smyth wrote:
>>>>>>>>>>
>>>>>>>>>> Anyone?
>>>>>>>>>>
>>>>>>>>>> On 25 July 2011 15:52, Thomas Smyth wrote:
>>>>>>>>>> > Upon further inspection I'm seeing that writing the timestamp is
>>>>>>>>>> > actually handled in the JavaRosa libraries, right here to be specific:
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > https://bitbucket.org/javarosa/javarosa/src/522ade3f6e72/core/src/org/javarosa/core/model/utils/DateUtils.java#cl-210
>>>>>>>>>> >
>>>>>>>>>> > It seems that Clayton Sims added timezone support here about four
>>>>>>>>>> > months ago. Could it be that the javarosa libs in the odk package are
>>>>>>>>>> > just out of date?
>>>>>>>>>> >
>>>>>>>>>> > I compiled up the latest version of javarosa and then compiled it into
>>>>>>>>>> > ODK and installed it on my device, but I'm getting a wretched
>>>>>>>>>> > exception and force close when I try to submit a form:
>>>>>>>>>> >
>>>>>>>>>> > java.lang.VerifyError:
>>>>>>>>>> > org.odk.collect.android.activities.InstanceUploaderActivity
>>>>>>>>>> >
>>>>>>>>>> > I tried a clean build and still nothing so I don't know what's up
>>>>>>>>>> > there. But perhaps if someone smarter than me could update the ODK
>>>>>>>>>> > repository with the latest JavaRosa libs we should get timezones for
>>>>>>>>>> > free!!!
>>>>>>>>>> >
>>>>>>>>>> > Thoughts?
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > On 25 July 2011 14:43, Thomas Smyth wrote:
>>>>>>>>>> >> Is there any reason the times stamped are not UTC? It seems this would
>>>>>>>>>> >> be optimal but it seems it's also too late to implement this as it
>>>>>>>>>> >> would be a nightmare for backwards compatibility, no?
>>>>>>>>>> >>
>>>>>>>>>> >> So I propose we patch it to include the timezone in the ISO 8601
>>>>>>>>>> >> complaint way, like so:
>>>>>>>>>> >>
>>>>>>>>>> >> 2011-07-25T10:11:09.320-0400
>>>>>>>>>> >>
>>>>>>>>>> >> instead of just
>>>>>>>>>> >>
>>>>>>>>>> >> 2011-07-25T10:11:09.320
>>>>>>>>>> >>
>>>>>>>>>> >> Any objections? I would imagine most code on the receiving end would
>>>>>>>>>> >> deal with this without any modification. A really picky regex parsing
>>>>>>>>>> >> method might have to be tweaked. But at least it will be clear when a
>>>>>>>>>> >> string has timezone, so any without should be treated as local time
>>>>>>>>>> >> (on the phone).
>>>>>>>>>> >>
>>>>>>>>>> >> I suppose another option might be to include both versions in a
>>>>>>>>>> >> space-separated string, like
>>>>>>>>>> >>
>>>>>>>>>> >> 2011-07-25T10:11:09.320 2011-07-25T10:11:09.320-0400
>>>>>>>>>> >>
>>>>>>>>>> >> But this seems like it would be just as likely to cause processing
>>>>>>>>>> >> errors.
>>>>>>>>>> >>
>>>>>>>>>> >> Anyway I can write this patch once we decide on the best way.
>>>>>>>>>> >>
>>>>>>>>>> >> Thoughts?
>>>>>>>>>> >>
>>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>