Wrong Time Recorded - Possible Bug?

[Michael2]

So far this behavior has only been observed on one device. The device is an iOS phone.

When the user creates a new row, one field records the current dateTime through the use of the NOW() expression. The problem seems to be that the recorded time is behind the actual current time. Depending on how long it has been since the user last created a new row, the recorded time may be off by several minutes, hours, or days.

So far, this behavior has only been observed by one user, on the one device and one app.

Initially, manually syncing seemed to be the solution but that doesn’t actually seem to work. Any ideas as to why this is happening would be appreciated.

[Steve]

If the new row is added from a form, and the current time is captured in a column of that row using the expression, NOW(), as either an Initial value or an App formula, the time will reflect when the form was opened, not when it was saved.

[Michael2]

The behavior described is not the result of the form having been left open for a time before being saved. I observed the behavior myself this morning. I opened the form and created a new row and the time was off by 4 days. Prior to my creating this row, the last row was saved/created 4 days ago.

After I created this new row, the behavior has persisted. The next rows were off by an hour or so.

[Austin]

If you create multiple rows back to back are they off by the same time after the first new row is added?
What I’m wondering is do they stay consistently off by X time when adding lots of rows, not just like 2 rows.

[Michael2]

I’ll get with the user and try that tomorrow… Thanks for your interest.

[Steve]

I would have to guess the problem is the user’s device; I’ve never heard of this behavior otherwise.

Is the device’s time correct? Does the time recorded by AppSheet reflect the device’s time?

How is the device’s time set: manually, or from the network?

Is the device fully up-to-date? Not just AppSheet, but the operating system and other installed apps, too?

Is the device still supported by the manufacturer?

Does the device have any questionable, possibly malicious apps installed?

Does the user play games on the app, and adjust the device time for the games?

[Ksenia1]

Hello,

Steve:

when the form was opened , not when it was saved

@Steve, I am working on an App in which users track their sick notes.

Recently, we found some rows in the database, where the timestamp (second column in the screenshots) had a two month gap to the sick leave date (fifth column).

While I find the chances quite low of leaving the Form View open in the device for two months before completing it, I would take that as an answer. But then again, it is suspicious that this happened to at least three users in the same period of time. By looking up the affected users in the database, I found that they had previously submitted forms with a timestamp dated after the one in their latest entry:

Any idea how that can happen or is that a case for AppSheet support?

[Steve]

How are each of those columns given their values? Are any actions, workflows, reports, or bots involved? Can the forms be reopened after their initial save?

[Ksenia1]

User: initial value = USEREMAIL(), show set off,
Timestamp: type DateTime, initial value = NOW(), show set off,
from date: type date, initial value = NOW(),
to date: type date, valid if [_THIS]>=[from_date]
(I hope that answers the first question)

Heaps of workflows to send out emails to corresponding addresees and an action to show a “popup” after submitting the form are involved.

There is a view sliced by the condition email_address = USEREMAIL() so that users can see their submitted forms. But the forms cannot be edited after saving.

[Steve]

I’m confused: you’ve referred to columns as “timestamp”, “sick leave date”, “from date”, and “to date”. Which are which? Are “from date” and “sick leave date” the same thing?

Based on the information you’ve given me, it would seem the user has the freedom to set the “from date” to any date they want, so I’m confused why you question the difference between the timestamp and the “from date”. Can you clarify?

[Ksenia1]

Sorry for confusing you

Timestamp is the second column in my screenshots and has the function to capture the datetime when the user has added this row. (Yes, set at the time when the user opens the form not when he saves it).

With “sick leave date” I mean the “from date” (fifth column in screenshots).

The user has the freedom to set both “from” and “to” dates. But he cannot set the timestamp column. The user submitted his sick leave for April 23 with a timestamp in February, which was confusing to me. Also, same user had already entries in the sheet dating March 15 and April 13, which makes me question the timestamp in his latest add.

I hope that is somehow understandable?

[Steve]

Given that the user can set the “from date” and “to date”, I see no reason to suspect a technical problem as the cause of the unexpected dates. I’d instead suspect user error. Have you asked the app user about the entry?

[Ksenia1]

Thanks for your estimation. Though, I am not entirely convinced No, I have not reached out to any of the affected users yet.

[Mickey]

I have similar issue related to this, why does timenow() reset to 12.00am after saving the form despite the device time being correct??

[Mickey]

why does timenow( ) reset to 12.00am after the form is saved??

[Austin]

I have had records that come in with weeks ago on their load dates because Appsheet creates the time stamp when you open the form not when the row was added. Also depending on if you have delayed sync enabled, users maybe be sending their changes much later. I have also had instances where users will quickly send 4-5 changes and then close their phone and the last change or 2 are still waiting to be synced over but since the app is closed it doesn’t sync. This is a very annoying thing for sure that syncs don’t continue in the background of a phone but are saved on the phone. As a data admin it makes it hard to show that their change wasn’t sent through because it immediately updates when they open their phones and “Look it’s right there”.

[Bahbus]

And if this particular user either denies/refuses changing system time and messing things up, an alternative method would be to use a workflow for after the form is saved to add the datetime. I think NOW() in a workflow uses the servers time, but if the user is offline when submitting new information, then the workflow will be delayed. You could try using some kind of combination of both and comparing, but that is getting potentially excessive.

[Michael2]

It turns out that the user was opening the form an leaving it open for a time before saving it. I have instructed the user not to do that. Hopefully this resolves the issue.

Thanks for everyone’s input.