TIME RECORDS · ENGLISH BUYER GUIDE
Make charging records agree on time before accepting the export
By Xiaochong Energy · · 6 min read
A charger log, operator dashboard and payment report can describe the same session using different clocks or display settings. Before blaming a missing transaction on hardware, ask what each timestamp actually means. Put a small time-record acceptance pack into the purchase scope so the operator can reconstruct a session without guessing which day, offset or event a column represents.
This is a proposed procurement method, not a claim that every charger, backend or payment product exposes every field. Exact capabilities and interfaces require model- and project-specific confirmation. Do not change clocks, security settings or live payment records to perform these checks. Use provider-approved test environments and qualified integration personnel.
1. Give every time field a meaning and an owner
Ask each supplier for a sample export and a field dictionary from the proposed configuration. A column called “time” is not enough. Identify the event represented, the system that writes it, its precision, its time basis and what happens when the information is unavailable. Do not treat a blank value or a default date as a valid event.
| Record to identify | Question for the responsible provider |
|---|---|
| Charging event time | Which event is recorded, and which device or service supplies this time? |
| Backend receipt time | When did the backend receive the record? Is that stored separately from the event time? |
| Payment event time | Is this authorization, capture, reversal or another defined event? Which payment reference joins it to the session? |
| Report display time | Does the dashboard or downloaded file convert the source value? Which setting controls the conversion? |
| Export generation time | When and with which filters was this evidence pack generated? |
Confirm the charger model, firmware, backend release, export version and payment integration used for the sample. If an important field is unavailable, ask for the supported alternative and document the limitation before ordering. Do not request passwords, private keys or customer payment details to fill the evidence gap.
2. Preserve the time basis, not just the clock face
RFC 3339 describes an Internet timestamp format with explicit UTC or numeric-offset information. Its local-time discussion explains why an unqualified local time is ambiguous for interchange; it does not define local time-zone rules. Treat this as a reference for interpreting sample records, not as proof of charger interoperability or certification.
For example, the fictional values 2026-10-02T00:15:00+03:00 and 2026-10-01T21:15:00Z identify the same instant. Their displayed calendar dates differ. A spreadsheet that removes the offset can hide this relationship. These are illustrative records, not measurements from a customer or a claim about a destination country's time rules.
Keep the original exported value alongside any normalised analysis column. Ask the backend provider to state the site's configured time zone, the operator account's display setting and the report's date-filter basis. An explicit offset alone does not prove that the underlying clock was accurate.
3. Join records by identity before comparing times
Use the agreed station, output, session and payment references to join records. Do not match only by a nearby start time: two outputs may be active close together, and different systems may report different events. Start with the asset-identity register so a cabinet label and backend identity cannot be silently confused.
In a fictional pilot, an event is recorded at 21:15 UTC and reaches the backend at 21:27 UTC after an approved disconnected test. The twelve-minute difference is a receipt delay in that example, not automatically twelve minutes of charging or clock error. Ask the provider how the actual system preserves, flags or reconstructs delayed evidence; never assume that every product keeps both fields.
Compare the joined record with the agreed metering and billing evidence. A timestamp by itself proves neither delivered energy nor successful payment. Resolve identity and event definitions before calculating a duration or changing a bill.
4. Agree a small set of boundary tests
Ask the providers to propose controlled test data for the cases below. State expected results before running the test, then retain sanitised exports and screenshots against the exact software revision.
- Ordinary session: trace the agreed start and end events across the charger, backend and any payment service. Explain each difference rather than demanding identical text in every display.
- Date boundary: include a session spanning the agreed reporting midnight. Confirm which report includes it and whether energy or revenue is allocated by a documented rule.
- Delayed record: review a provider-approved offline/recovery example. Check whether a later report changes and how the correction remains traceable.
- Offset-change case, where relevant: use approved historical or synthetic data for a skipped or repeated local clock interval. Require the backend owner to confirm applicable zone rules rather than inventing a country's transition date.
- Uncertain time: ask how invalid, unsynchronised or missing source time is represented and escalated. Do not silently accept a plausible-looking replacement as original evidence.
The offline-operation checklist addresses disconnected behaviour more broadly. This time-record review does not authorize disconnecting live equipment or editing production clocks. Such changes can affect functions outside the report being tested.
5. Define accuracy and correction evidence separately
Ask the integration team to identify the supported time source, synchronisation responsibility and evidence available when synchronisation is unavailable. Agree a project-appropriate tolerance with the responsible providers. This guide deliberately specifies no universal number of seconds and does not prescribe a network or security configuration.
Keep three questions separate: can the value be interpreted; does it identify the intended event; and is the clock sufficiently accurate for the agreed use? Passing the format check answers only the first question. If a provider corrects data, ask how the original value, correction reason, authorisation and resulting report revision can be traced.
Do not overwrite original evidence in a spreadsheet to make totals agree. Maintain an exception list containing the affected references, the observed mismatch, the owner, the agreed disposition and any unresolved commercial impact. Retain only authorised, necessary data under the project's privacy and retention requirements.
6. Attach the evidence to the commercial scope
Specify who supplies the field dictionary, sample records, configuration record and export access. Confirm whether the agreed exports are included, require a platform subscription or depend on a third-party service. Put recurring costs and access rights into the software licence review.
Close the acceptance pack with the tested baseline, expected and observed results, unresolved items and named sign-off owners. Recheck affected evidence when firmware, backend, payment configuration or reporting settings change. Do not infer permanent compatibility from one successful sample.
Use the RFQ brief builder to request the evidence package and list unknowns. It organises procurement questions; it does not approve electrical design, billing law, payment-network compliance or cybersecurity.
AC and DC cooperation scope
AC EV charger SKD kits and technical documentation: agree the selected AC model, supplied components, controller/interface documentation and production, testing and service responsibilities.
DC EV charger SKD kits and technical documentation: agree the selected DC configuration, output identities, component scope, supported session evidence and qualified integration and repair-support responsibilities.
Xiaochong recruits businesses interested in local charger production or assembly, with SKD components, production/assembly technical support and repair/maintenance technical support scoped per project. Available AC or DC technical documentation is free on request. Hardware, unrestricted source code, all intellectual property, certification, training, repair labour and exclusive territory rights are not automatically free. Confirm exact models, document revisions, licensing, training, testing and support deliverables in writing.
Buyer questions
Is a backend receipt timestamp the same as the charging event time?
Not necessarily. Ask the providers to identify when each field is created and how delayed records are handled. Keep original event time and receipt time distinct where available; do not infer one from the other.
Does an explicit UTC offset prove that the charger clock is accurate?
No. An offset makes the recorded time interpretable, but clock accuracy and synchronisation still require separate evidence and agreed acceptance criteria.
What should a time-record acceptance pack contain?
Include the tested hardware and software baseline, field definitions, original timestamp values and offsets, station and session references, export settings, expected results, observed results and unresolved limitations.
Reference reviewed 2 October 2026: RFC 3339, especially local time and timestamp examples. The procurement checklist and fictional records are Xiaochong's original guidance, not a protocol conformance test.
Request the AC or DC evidence scope
Send your country, company, AC or DC track, intended model, quantity and proposed operator platform. Ask for free available AC or DC technical documents and identify the session/export evidence you need. Confirm any third-party responsibilities with the relevant provider.
See the official partner programme, AC/DC SKD technical-output page and procurement guide. Only approved documentation may be shared; this article does not publish internal factory files.
xc0225888@163.com · Sales 1: +86 137 1772 6888 · Sales 2: +86 134 2580 6997