datetime issue (DST?) in Indian Standard Time

[MartijnR]

see report here: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/enketo-users/QlL6b77X7Xk/qK0uuYypBwAJ

The user only sees this when loading a draft record in Enketo Express, but we should try to reproduce in Enketo Core (unlikely caused by code in Enketo Express).

1. Set computer to IST
2. Collect datetime in test form (single question form). Check how it is stored in model
3. Load record with that the value from 2. Check how it is displayed in form.

[peterMuriuki]

Hi @MartijnR I am interested in working on the issue and I would like guidance on how to work on the issue; like files to check

[MartijnR]

Hi @p-netm,

That's great. I think the first step is to see if the issue is caused by some conversion in enketo-core (or enketo-xpathjs). The way to do that is follow the steps above (you can get the current state of the record with form.model.getStr() in the console. And use that record during instantiation (by temporarily editing app.js).

If the issue turns out to be caused by enketo-xpathjs, I would be less interested in a fix, because that whole library is in the process of being replaced.

It may also be good to turn off the datetime widget (in widgets.js) to see if the cause lies there.

Have fun!

[peterMuriuki]

Hi @MartijnR So i havent really had any sort of progress other than replicate the issue:

Looking into the console: for a simple form with only a time question; this is the saved draft during set, after filling in 7:00 PM

{draft: true, xml: "<timetest xmlns:jr="http://openrosa.org/javarosa" …instanceID>↵          </meta>↵        </timetest>", name: "timetest - 5", instanceId: "uuid:43300a16-ec8d-4866-aa1a-d8e35a377bbb", deprecateId: "", …}
deprecateId: ""
draft: true
enketoId: "phrdF0lH"
files: []
instanceId: "uuid:43300a16-ec8d-4866-aa1a-d8e35a377bbb"
name: "timetest - 5"
xml: "<?xml version="1.0" encoding="UTF-8"?>
<timetest xmlns:jr="http://openrosa.org/javarosa" xmlns:odk="http://www.opendatakit.org/xforms" xmlns:orx="http://openrosa.org/xforms" id="timetest" version="201907311209">
   ↵
   <formhub>
      ↵
      <uuid>a4d96ea10a7b43688036288d4bca4467</uuid>
      ↵
   </formhub>
   ↵
   <wakeup>19:00:00.000+06:30</wakeup>
   ↵
   <meta>
      ↵
      <instanceID>uuid:43300a16-ec8d-4866-aa1a-d8e35a377bbb</instanceID>
      ↵
   </meta>
   ↵
</timetest>"

After reloading the same record from drafts and then resaving it again : the saved instance looks like this:

deprecateId: ""
draft: true
enketoId: "phrdF0lH"
files: []
instanceId: "uuid:43300a16-ec8d-4866-aa1a-d8e35a377bbb"
name: "timetest - 5"
xml: "

<?xml version="1.0" encoding="UTF-8"?>
<timetest xmlns:jr="http://openrosa.org/javarosa" xmlns:odk="http://www.opendatakit.org/xforms" xmlns:orx="http://openrosa.org/xforms" id="timetest" version="201907311209">
   ↵
   <formhub>
      ↵
      <uuid>a4d96ea10a7b43688036288d4bca4467</uuid>
      ↵
   </formhub>
   ↵
   <wakeup>19:00:00.000+06:30</wakeup>
   ↵
   <meta>
      ↵
      <instanceID>uuid:43300a16-ec8d-4866-aa1a-d8e35a377bbb</instanceID>
      ↵
   </meta>
   ↵
</timetest>

"

What i think is peculiar is that in between reloading the draft and resaving the draft, the time value is decreased by an hour however the resaved draft xml is similar to the original draft, specifically the wakeup node value.

Another flag is the value of the wakeup node: 19:00:00.000+06:30, given that IST is +05:30 could this be a pointer to where the problem lies or is this the expected behaviour

Am hoping this information can help you help me zero down to what could be the cause of the issue

[MartijnR]

Thanks! That's interesting. Good to know that the model value is consistent at least. So 2 issues:

1. time value displayed in the widget after loading the record is inconsistent with the original data entry (model value is the same)

2. IST is getting the wrong timezone offset

For 1, it would be good to know if that issue is occurring when you disable the time widget (comment out the line in widgets.js).

For 2, Enketo is using this code which uses the browser engine's native Date object. Does the offset differ between FF/Chrome/Safari perhaps?

[peterMuriuki]

Sorry, for the huge time gaps within the response, And also thanks for the quick replies. Soo just inspecting no 2. now, and i found this, which explains the the wrong timezone offset.

// timezoneOffset = -330;
Math.floor( -330 / 60 )  // -6

I believe the intention here was to round off this to -5 but the result is -6.

[peterMuriuki]

If the issue turns out to be caused by enketo-xpathjs, I would be less interested in a fix, because that whole library is in the process of being replaced.

Should i write a fix for this, in the enketo-xpathjs repo

[MartijnR]

Oh my... :sweat_smile:

Thank you for finding this! Yes, this embarrassing bug should actually be fixed in enketo-xpathjs, so a PR is very welcome after all!

[MartijnR]

• [ ] add failing test in enketo-core. I think the bug is caused here
• [ ] update enketo-xpathjs to version 1.9.3 to fix