In this article, we will go over where the date and time stamps come from, why a device must use its Automatic Date and Time setting with the Silvertrac Mobile App, and how to tell if a device has been manually changed to a different Date and Time after login.
Silvertrac, date, and time stamps all activity created in the Mobile App and on the issue monitor.
Silvertrac also dates and times stamps when issues and activity upload to the Issue Monitor servers from the Mobile App. This allows you to run an Issue History report and see any server upload delays caused by dead zones or disruption of Internet connectivity.
Because all real-time reporting apps rely on the device's internet connection, having an accurate record of when an issue was created and uploaded can be an essential factor in risk and liability mitigation cases, as you will see in the Case Study below.
Where Does Silvertrac Get the Date and Times Stamps From?
The Issue Monitor
The System Administrator sets up the Issue Monitor web portal by Time Zone.
This means that if reporting officers create activity and issues in multiple time zones, the system will recognize the date and time in the Issue Monitor based on the System Config General Settings.
For example: if your Web Portal is set to UTC-5:00 Eastern Time (US & Canada) and it is 12:00 PM, but the officer is reporting activity in UTC-6:00 Central Time (US & Canada) at that exact time, the Issue monitor will display the activity date and time stamp as 11:00 AM.
NOTE: If you report with the Silvertrac mobile app in multiple time zones, adding an additional web portal for each time zone you operate in is highly recommended.
The Mobile App
The date and time stamps for all the issues created in the Silvertrac Mobile App use the device's date and time settings.
Why Must a Reporting Device's Date and Time be set to Automatic to Work with the Silvertrac Mobile App?
If a Silvertrac Mobile App user could change the Date and Time settings manually, they would then be able to manipulate data, undermine the integrity of real-time reporting, and render it inadmissible in litigation or subpoena.
How to Tell if a Device has been Manually Changed to a Different Date and Time After Login
Case Study
An officer completed a checkpoint tour of a property with device settings set to automatic. The checkpoint tour required that the officer take a photo at each checkpoint.
The officer then manually changed the Date and Time settings on their reporting device to the following Friday and completed the same tour again with photos.
The Property Manager received the DAR with checkpoints and photos, which were reviewed the following Monday.
The following week the officer did not show up to the post. However, because he had done a tour the previous week with the future date and time stamps, his activity was uploaded into the issue monitor in "real-time." It appeared as if he was on site completing a checkpoint tour.
The Property Manager again received the DAR with checkpoints and photos, which were reviewed the following Monday. However, the observant Property Manager noticed that one of the photos of the mailroom included a holiday wreath that had been removed that week.
It was seemingly impossible to reconcile the missing wreath with the activity date and time stamps, calling into question the validity of Silvertrac's "real-time" reporting software.
It was also seemingly impossible to take disciplinary action for officer abandonment of post since the officer had produced date and times stamped activity for that day.
Resolution. Running an Issue History report verified when the secondary checkpoint tour with the manually adjusted date and times had been uploaded to the server.
The Issue History Report
The Issue History report is a CSV (comma-separated value) spreadsheet.
Columns M through Q show the Date and Time stamps that were obtained from the deporting device on the Silvertrac Mobile App:
Reported on a device in the Silvertrac Mobile App:
The Issue History report also displays the Date and Time stamp of when the issue was uploaded to the server (Column X) and if and how much of a delay there was in minutes for the issue to upload to the server (Column Y):
NOTE: It typically takes an issue between 20 and 60 seconds to upload to the server with good internet connectivity. It takes audio files and photos, typically 1 - 2 minutes, to upload to the server with good internet connectivity. So Column Y should be in the 0 - 2 minute. If you note longer delay times, this is indicative of a dead zone or poor internet connection and that the issue is in the App's Pending Upload Queue.
In this Case Study, Column X showed the checkpoints original date and time stamps but column Y showed a delay in minutes of over 10,000 minutes!
The Property Manger and Security company owner were then able to go into those uploaded issues in the Web Portal and see the date and time stamps on the photos did not match, they were from the original reporting date a week earlier.
This issue was thus reconciled. The client was not happy that the checkpoint was not completed as reported, but was appreciative of the complete transparency by the Owner and the contract was saved. She was not charged for the checkpoint tour and appropriate disciplinary action for offending officer was dispensed.