🐝Bee-ing a Tester: I found a bug ..honey! . “Timezone Tango: When Data Dances to the Server’s Clock”. Bug #007: Server Overrides Device Timestamp with Its Own Local Time.

Severity:

High

Context:

The application collects data from devices located in different sites and timezones.

Steps to Reproduce:

1. Device collects data at a specific site and sends the payload with the correct collection timestamp.
2. API successfully delivers the timestamp to the server.
3. Server logs/store entry shows a different time (server’s local time instead of device’s reported time).

Expected Result:

The system should store and display the original collection timestamp from the device.
-If server-local time must be used, it should at least be clearly labeled as “Server Time” and not replace the true collection time.

Actual Result:

The database record displays the server’s local time instead of the actual collection time sent by the device.
-Receipts/reports generated from the system show misleading timestamps.

Impact:

• Users reviewing receipts see timestamps that don’t match the real collection events.
• Audit and traceability issues (data appears “shifted” in time).
• Can cause serious confusion when data comes from devices in different time zones.

Suggested Fix:

• Store both values:
  collection_time (from device, normalized to UTC).
  server_received_time (optional, for debugging/logging).
• Display collection time (with proper time zone conversion for UI).

Lesson learnt:

“When it comes to time, don’t let the server tell the story. always trust the device that was actually there.”

Let’s connect! I share common bugs, solutions, and QA tips regularly.