Keep the timestamp's unit when a request crosses systems
A numeric timestamp is not self-explanatory. The same integer can represent a useful current date in one interface and a date in 1970 in another. If a receiving system discards the unit in the source contract, choosing a different display time zone will not repair the instant.
This fictional example follows a New Zealand service request into a shared staff queue. The source interface supplies Unix time in seconds. The receiving JavaScript application constructs dates from numeric milliseconds. Both behaviours are documented for their respective boundaries, but the adapter treats the numbers as interchangeable.
Follow one request before changing the filter
Request R-61 arrives at 9:30 am on 18 November 2026 in Pacific/Auckland. Its retained source response records received_at as 1794947400, with the interface contract specifying whole seconds since the Unix epoch.
The shared queue is intended to show this current request. Instead, R-61 is absent from the current-period view. The source record exists, and the receiving application has stored the request reference, customer task and timestamp value. The failure is not evidence that the customer must submit again.
An authorised inspection of the imported record shows a date in January 1970. Before widening the filter or moving the request manually, the maintainer compares the original value, its declared unit and the conversion used by the adapter.
Locate the unit change
The adapter passes 1794947400 directly to the JavaScript Date constructor. For a single numeric timestamp argument, that constructor uses milliseconds since the epoch, as described in MDN's Date constructor reference.
The evidence is:
| Boundary | Value or interpretation |
|---|---|
| Source contract | Whole Unix seconds |
| Retained source value | 1794947400 |
| Incorrect constructor input | 1794947400 interpreted as milliseconds |
| Incorrect resulting UTC instant | 1970-01-21T18:35:47.400Z |
| Required millisecond value | 1794947400000 |
| Correct UTC instant | 2026-11-17T20:30:00Z |
| Correct Auckland view for that instant | 18 November 2026, 9:30 am, UTC+13:00 |
The original timestamp is intact. Its meaning is lost at the conversion boundary. Adding thirteen hours to the incorrect date would retain the wrong year and would introduce a second error.
The dated Auckland view uses the relevant time-zone rules. It is not a permanent New Zealand–US offset or a claim that all New Zealand locations share one zone. Another colleague can review the same record in UTC without changing the underlying instant.
Make the conversion follow the contract
The selected correction converts seconds to milliseconds at this source adapter, then stores the resulting instant in the application's agreed representation. It does not change every timestamp throughout the system or infer units from the number of digits.
The interface version and field definition belong in the mapping. A second endpoint might legitimately supply milliseconds. Applying the same multiplication there would be wrong. An unknown or contradictory unit must become an investigation item rather than a guessed date.
The source value and request identity are retained for diagnosis. Where the original data is sensitive, the diagnostic record should contain only what is necessary and follow the organisation's access and retention arrangement.
Demonstrate the corrected queue and its controls
In the worked example, the corrected import places R-61 at the expected instant. The current-period view includes R-61 according to its unchanged filter rule. Opening the request shows its original task and reference; no second enquiry is created.
The acceptance set also includes:
| Case | Required result |
|---|---|
| R-62 from the same seconds-based endpoint | Convert under that endpoint's contract and preserve its distinct received instant |
| A record from an independently documented millisecond endpoint | Use its value directly; do not multiply it again |
| Unsupported unit declaration | Hold for investigation without assigning a plausible-looking date |
| Malformed numeric value | Report an import problem; do not substitute the current time |
| View R-61 in UTC and Auckland | Show two representations of the same instant, retaining the same request identity |
| Reopen the original source record | Preserve the source timestamp and business content unchanged |
For example, the millisecond endpoint can supply 1794947400000 directly. It must reach the same UTC instant as R-61, even though the adapters perform different unit handling. That comparison demonstrates why magnitude guessing is unnecessary when the contract is known.
These are bounded fixture outcomes. They do not establish that every provider field uses Unix seconds, that every timestamp should be converted to JavaScript milliseconds or that an actual production queue has been tested.
Review affected history deliberately
A repair to future imports does not automatically establish the correct values for every older record. Identify records produced by the affected adapter and compare them with retained source evidence. Where that evidence is missing, preserve uncertainty instead of manufacturing a likely date from surrounding records.
Historical correction also needs authority. Staff may already have acted on a record or exported it elsewhere. A proposed migration should identify those dependencies and record what changed. The original request is not an invitation to repeat a customer or financial action.
Separate the instant from the business rule
A received timestamp does not decide when staff must respond, whether a booking is confirmed or which working calendar applies. Those rules come from the organisation. This correction establishes when R-61 was received; it leaves the approved queue period and review responsibilities intact.
For remote work, agree how timestamps are labelled in reports and discussions. A local display should identify its relevant zone or offset where ambiguity matters. Preserve the underlying instant so that a colleague using another display does not create a different event.
Bring the source field definition, a safe example value and the point where its date changes to system-connection work or the project conversation.