Cached geolocation in a hire condition note: record the reading's time
Keep a browser location reading’s acquisition time separate from the handover note and condition photos, with a clear label when cache use is unknown.
By AuditIt Editorial Team · Fact checked
What to know
- Keep the browser position’s acquisition time separate from note entry time and the condition photograph’s time.
- Cache acceptance depends on request options. If those details were not supplied, leave cache use unknown.
- A typed browser reading does not become an AuditIt live capture fact or a gallery import fact.
A browser location reading pasted into an equipment return note needs its source and acquisition time. Record when the note was entered separately. If nobody supplied the request options or said whether the reading came from a cache, leave cache use unknown.
Cache age is not the note’s age
W3C’s Geolocation document dated 5 November 2026 is a Candidate Recommendation Draft: work in progress, rather than a finished specification. It defines maximumAge as the acceptable age of a cached position, in milliseconds.
The processing steps set its default to zero. Reusing a cached position requires a positive value, a sufficiently recent cached timestamp and a matching high-accuracy setting. MDN’s method reference likewise says the zero default requires an attempt to obtain the current position. This option controls cache acceptance; timeout controls waiting.
Those are descriptions of a web API. A method name such as getCurrentPosition() cannot tell a hire-desk reviewer which options a particular application used. Keep the request details when they were supplied; a photograph cannot fill that gap.
One return, three time labels
Consider the fictional training asset EQ-084. All times below are on the same day in UTC. The supplied browser reading shows a position acquisition time of 10:02. A colleague enters the return note at 10:07, and a separate condition photograph shows a time of 10:08. The browser application and its request options were not supplied.
MDN defines the position’s timestamp as the time the device acquired that position. Entering the note at 10:07 does not move the supplied reading to 10:07. The photograph’s time belongs to its own record.
A useful entry for this example would read: “EQ-084 — browser position timestamp 10:02 UTC; entered in return note 10:07 UTC; source application, request options and cache use not supplied. Condition photo time shown: 10:08 UTC.” This is a proposed note format, not an AuditIt field list or a real customer record.
The entry leaves a specific question for the sender: which application produced the reading, and were its request details recorded? Until that information arrives, keep cache use unknown. The difference between the two clock values alone does not identify the request that produced the reading.
Keep a typed browser note distinct from capture facts
AuditIt uses capture facts for time, timezone offset, capture source and, when enabled, location and accuracy recorded for a live camera capture. Import facts describe when and how an existing gallery file entered the product; they do not stand in for that file’s capture time or location. A typed browser-reading note remains a submitted statement about another source.
When organization policy is on, AuditIt’s live-evidence disclosure requires the foreground location supplied by the phone. Approximate location is accepted and labeled approximate. Gallery imports never use the phone location. This article makes no claim that AuditIt’s mobile capture implements the W3C API or identifies whether a browser used a cache.
For the broader photo-record distinction, read capture facts versus import facts. The guides to location accuracy and altitude reference labels answer separate questions.
Where AuditIt fits
Choose the condition workflow for the job being recorded. equipment_checkout_return keeps checkout and return as a before-and-after comparison. equipment_damage_report and equipment_pre_hire_check are record-only templates for one visit. A copied browser figure does not choose between those workflows.
The equipment checkout-and-return guide explains the two-stage record. You can use the note format above in your existing process, or start an AuditIt account for structured condition records.
AuditIt creates tamper-evident, human-review-ready records. It is not legal certification and does not determine liability. A person still reviews the submitted reading alongside the photographs and notes.
Prepared with AI assistance and checked against the linked sources.
Direct answers
Frequently asked questions
Can getCurrentPosition return a cached reading?
A nonzero maximumAge can permit cache reuse under the API’s conditions. Check the recorded options and position timestamp; the method name alone does not establish what happened on that request.
Does the location timestamp date the condition photograph?
The position timestamp identifies when the position was acquired. Keep the photograph’s own time separate; a copied reading does not date that photograph.
What if the sender did not record cache use?
Mark cache use unknown and retain whichever source and acquisition-time details were actually supplied. Ask for the missing request information rather than reconstructing it from a photograph or a typed coordinate.
Sources
- Geolocation — Candidate Recommendation Draft, 5 November 2026, World Wide Web Consortium
- Geolocation: getCurrentPosition() method, MDN Web Docs
- GeolocationPosition: timestamp property, MDN Web Docs
- Capture facts vs import facts: keep them distinct, AuditIt
- geolocation
- cached position
- capture facts
- equipment rental
- condition records
