Hi all --
I notice in my data that, on rare occasion, some forms have come in that
show that the function today() has resulted in a date way back in 2012.
My theory on this is that
(1) the today() function looks to the phone's own clock to get the date
(2) the 2012 anomalies happen because the phone had had its battery die and
the clock got reset... and 2012 is the date that the phone reverts to when
clock battery died. (In my data, the phone seems to fix its clock within
... three weeks? If it's getting the date fix from the net, I wonder why
it took that long 
)
Can anyone smart tell me:
*** Is my thinking correct above...
*** Do you think it's only Samsung phones that predictably revert to 2012
after a battery dies, or is it all Android phones... or?
*** My hoping is that if 2012-after-dead-clock-battery is really a
consistent behavior, I could use "2012" to predictably detect and correct
those fields
thx
eric
Hey Eric,
(1) the today() function looks to the phone's own clock to get the date
Yes, this is the case in CommCare.
I've heard anecdotes where form dates will be way off because users will
change the device's clock to play games with daily limits, like Candy Crush.
Another thing to look out for is that sometimes changing your device's
clock will result in issues logging into CommCare. This stems from the fact
that when CommCare establishes a secure connection with the server it uses
security certificates that are only valid between certain date ranges.
(2) the 2012 anomalies happen because the phone had had its battery die and
the clock got reset... and 2012 is the date that the phone reverts to when
clock battery died. (In my data, the phone seems to fix its clock within
... three weeks? If it's getting the date fix from the net, I wonder why
it took that long )
I've never experienced this, but sounds plausible. As far as I know,
electronic devices usually have a special backup battery just for the clock
to prevent such occurrences. Maybe your device doesn't have a backup
battery or it is faulty?
*** Do you think it's only Samsung phones that predictably revert to
2012 after a battery dies, or is it all Android phones... or?
My guess is that this behavior is going to be very device specific.
*** My hoping is that if 2012-after-dead-clock-battery is really a
consistent behavior, I could use "2012" to predictably detect and correct
those fields
Yeah, you could definitely validate input to detect this issue. If it is
the case that the clock doesn't reliably default to 2012, you could add a
lookup table into your app that stores the current year. Since you are
checking that the inputted date is above that year, it would be fine for
this 'current year' date to become stale (as it might if users don't sync
with HQ when you update the lookup table)
Best,
···
--
Phillip Mates
Mobile Engineer at Dimagi
Hi Eric,
Confirming that the behavior of returning to a hard date is common on
phones, but it's generally more-or-less the date of manufacture for the
device, so will be hard to generalize super well. Phillip's suggestion is
probably the best in terms of having an easy way to provide hard cue for a
validity window,
-Clayton
···
On Tue, Oct 18, 2016 at 7:51 AM, Phillip Mates wrote:
Hey Eric,
(1) the today() function looks to the phone's own clock to get the date
Yes, this is the case in CommCare.
I've heard anecdotes where form dates will be way off because users will
change the device's clock to play games with daily limits, like Candy Crush.
Another thing to look out for is that sometimes changing your device's
clock will result in issues logging into CommCare. This stems from the fact
that when CommCare establishes a secure connection with the server it uses
security certificates that are only valid between certain date ranges.
(2) the 2012 anomalies happen because the phone had had its battery die
and the clock got reset... and 2012 is the date that the phone reverts to
when clock battery died. (In my data, the phone seems to fix its clock
within ... three weeks? If it's getting the date fix from the net, I
wonder why it took that long )
I've never experienced this, but sounds plausible. As far as I know,
electronic devices usually have a special backup battery just for the clock
to prevent such occurrences. Maybe your device doesn't have a backup
battery or it is faulty?
*** Do you think it's only Samsung phones that predictably revert to
2012 after a battery dies, or is it all Android phones... or?
My guess is that this behavior is going to be very device specific.
*** My hoping is that if 2012-after-dead-clock-battery is really a
consistent behavior, I could use "2012" to predictably detect and correct
those fields
Yeah, you could definitely validate input to detect this issue. If it is
the case that the clock doesn't reliably default to 2012, you could add a
lookup table into your app that stores the current year. Since you are
checking that the inputted date is above that year, it would be fine for
this 'current year' date to become stale (as it might if users don't sync
with HQ when you update the lookup table)
Best,
--
Phillip Mates
Mobile Engineer at Dimagi
--
You received this message because you are subscribed to the Google Groups
"commcare-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to commcare-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.