Wrong Time Recorded - Possible Bug?

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.

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.

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”.

1 Like

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.

1 Like

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.

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

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?

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.

1 Like

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.

1 Like