Adjust data to account for down time

[KateCourt]

The Logger stopped recording on 21/06/2023 at 16:00

It did not come back on again until 22/06/2023 around 10:38 - however, when it started logging again, it resumed from 21/06/2023 at 16:00 appearing as if there was no gap in time but there was a rapid drop in temperature observed within 15 mins.

This has put the data 18 hours and 38 minutes behind where it should be.

When downloading any dataset from that weather station, data starting from the 21/06/2023 at 16:00 has to be moved down to 22/06/2023 at 10:38 to be correct.

I am going to reset the time on the logger today (09/07/2024) at 14:00 pm so that it is logging at the proper time once again.

[KateCourt]

To do this:

• Replicate the database on our local Atlas instance or create test collection on their database
• Write script to correctly offset and test data
• Implement this on the production data

[Robin-Wardle]

Some preparatory questions about the DB installation. We understand the database is MongoDB.

1. What mongod version is running? Does it get updated / maintained?
2. We understand it's running on a NUIT VM.
   • is this an Ubuntu or Windows VM? What versions?
   • is it a single VM installation, i.e. it's not running on a replica set across 3 nodes?
   • is the VM and / or the DB backed up (not just snapshots)?
3. Can the DB be connected to from anywhere on the university network through a visual client (e.g. Compass) or mongosh?
4. We would need administrator-level access, who controls this?
5. Is the VM firewalled?
6. How large is a) the entire database and b) the collection with the timestamp problem?
7. What other services would be affected if the DB is offline for any length of time?