The clock changes; the order of events must stay clear
UK clocks go back on Sunday 25 October 2026. GOV.UK confirms the date and the autumn change at 02:00; the National Physical Laboratory explains that this is 02:00 BST, when the clock returns to 01:00. The hour labelled 01:00 to 01:59 therefore occurs twice. For an overnight gate team, two movements showing the same local time need not be duplicates.
The practical question is whether staff can distinguish those occurrences when recording a vehicle, handing over an open visit or reviewing a report. A screen that looks sensible on an ordinary Tuesday is not sufficient evidence. This guide's sources were checked on 20 October 2026, and the examples below are fictional tests, not records from a customer.
Priority Service advertises time-stamped IN and OUT records, guard shift records and administrator CSV reporting. Its public descriptions do not establish the stored time convention, clock source or repeated-hour export format. Treat the checks below as questions to demonstrate, not claims that a particular internal implementation has already been verified.
Separate a clock label from a particular moment
NPL distinguishes the seasonal change in displayed UK time from UTC, which is not put back for the autumn change. Before the transition, BST is one hour ahead of UTC; afterwards, the UK returns to GMT. A time written only as '25 October, 01:30' does not identify which occurrence was intended.
For a concrete example, 2026-10-25T01:30:00+01:00 means the first occurrence, equivalent to 00:30 UTC. 2026-10-25T01:30:00+00:00 means the second, equivalent to 01:30 UTC. They are an hour apart. These are illustrative timestamp formats, not promised Priority Service export values.
RFC 3339 documents internet timestamps with dates and UTC offsets. The operational lesson is to retain enough information to identify the moment: for example, a UTC timestamp or a local timestamp with its correct offset. Adding seconds to an otherwise ambiguous local time does not solve the repeated-hour problem.
Test a visit whose OUT label appears earlier than IN
Use this fictional visit on 25 October: IN at 01:50 BST, then OUT at 01:10 GMT. The arrival corresponds to 00:50 UTC and the departure to 01:10 UTC, so the elapsed visit is 20 minutes. Subtracting the two bare clock labels instead would give a misleading negative result.
Ask the supplier to demonstrate how such a visit appears in the guard workflow, administrator history and exported report, using a controlled test environment or prepared fictional records. Check that the departure is linked to the intended arrival and that the sequence remains understandable. Do not alter a live phone's clock or fabricate movements in production to run the exercise.
If the displayed labels are ambiguous, ask how an authorised reviewer obtains the underlying timing information. Do not correct the apparent reversal by moving a timestamp forward an hour. First establish the time convention and the original records. An unexplained manual adjustment can conceal the very evidence needed to understand the visit.
Check devices without assuming they set the record time
Google's Android guidance describes separate automatic date-and-time and time-zone settings, with availability varying by device. Have the responsible administrator check the intended configuration on the actual gate handset and any spare. Follow the organisation's device policy and approved support instructions rather than changing settings independently during a shift.
Then ask a different question: what sets each application timestamp? A phone display, capture time, server receipt time and approval time are not necessarily the same thing. Confirm which event each field represents and what happens if a save is delayed. The fact that the handset changes its clock correctly does not answer those application questions.
IANA maintains time-zone rules and explains that users normally receive updates through software and operating-system vendors. Ask the supplier how UK seasonal rules are applied across the app, administration and reports. A fixed offset of one hour ahead of UTC is not a year-round definition of UK local time.
Make the overnight handover and report window explicit
For a shift scheduled from 19:00 on 24 October to 07:00 on 25 October, the elapsed interval is 13 hours because the clock goes back during it. This is time arithmetic, not a conclusion about pay, breaks or contractual entitlement. Have the responsible manager agree staffing and employment arrangements separately.
Specify the handover using the date and an unambiguous time convention. Include which visits remain open and who owns any outstanding approval. If a handover or planned action falls within the repeated hour, identify the intended occurrence rather than writing '01:30' and expecting both teams to interpret it identically.
Check daily filters as well as shift filters. The UK local calendar day of 25 October contains 25 elapsed hours. Ask whether a report for that date includes both occurrences of the repeated hour and how cross-midnight visits are selected. Do not assume that requesting a local date is equivalent to requesting a fixed 24-hour UTC interval.
Preserve the meaning when opening a CSV report
Export a controlled example and retain the original file before analysing a copy. Identify the timestamp columns, their documented time convention and the fields linking the arrival, departure, site and guard. Confirm what the report actually includes; do not assume it supplies UTC, offsets, record identifiers or a calculated duration.
Microsoft explains that Excel uses default data-format settings when opening CSV files and offers import options for controlling interpretation. Inspect the raw text alongside the imported result. Where needed, use a controlled import and preserve the original timestamp text while preparing separately checked analysis columns. Changing a cell's display format cannot restore an offset that was never present.
RFC 3339's text-sorting shortcut has conditions, including a consistent time-zone representation and precision. Do not assume mixed-offset timestamp strings sort into event order merely because they resemble a standard format. Use a correctly parsed, common time basis for chronological analysis and keep the original values available for review.
Reconcile other systems before alleging a missing movement
A client may compare a gate visit with CCTV, a delivery note or another system. Establish each source's time convention and any known clock discrepancy before deciding that the accounts conflict. A camera showing 01:15 and a report showing 01:15 do not necessarily refer to the same moment on the changeover night.
Preserve original observations and explain any comparison or conversion in the review notes. If a source contains only an ambiguous local label, state that limitation and seek authorised supporting context rather than inventing the missing offset. A plausible explanation is not the same as evidence that the timing has been resolved.
Use the same discipline with temporary paper records. Under the site's agreed fallback, include the date and a clear BST or GMT designation for an observed time where staff can establish it. If they cannot, record the uncertainty and refer it for reconciliation. Never ask guards to manufacture precision after the event.
Agree acceptance before the changeover night
Before 25 October, nominate an administrator to check the repeated-hour visit, the overnight handover and the CSV interpretation. Record the demonstrated outcome, any unresolved limitation and who will handle a timing query. Include the receiving manager who actually uses reports, not only the person operating the phone.
Pass the exercise when the reviewer can distinguish the two occurrences, explain the example's 20-minute duration and account for the requested reporting window. If that cannot be shown, agree a documented interim review procedure with the supplier and site manager. Do not declare the records wrong solely because a local-time label appears to run backwards.
Review Priority Service's published features at https://priorityservice.co.uk/#features and request a demonstration at https://priorityservice.co.uk/#demo. Bring this fictional changeover example and ask to see the actual record and export behaviour. The buying test is simple: can your team explain when a movement happened without guessing which 01:30 it was?
Sources & further reading
- GOV.UK: UK clock-change dates, including 25 October 2026
- National Physical Laboratory: BST, UTC and the autumn transition
- RFC Editor: RFC 3339 timestamp offsets and ordering
- IANA: Time Zone Database and vendor updates
- Google: Android date, time and time-zone settings
- Microsoft: CSV import and data-format interpretation
- Priority Service: Published app features
- Priority Service: Request a demo
Vehicle logging for your operation
Explore the workflow, plans and demo options for your team.
Explore gatehouse management software
Compare gate management plansSEE THE WORKFLOW IN PRACTICE
Explore Priority Service at your gate.
See vehicle capture, permits, approvals and reporting in a demonstration built around your requirements.
Request a demoExplore the app features