Find the conversion that sends a future review date into 1901

A long-horizon maintenance record reaches a receiving tool with the correct reference and the wrong century. Before blaming a time zone, inspect the numerical conversion between the source and destination. A value can be valid in both systems yet be narrowed by an unnecessary intermediate operation.

This worked example uses a fictional equipment-record integration and explicit test dates. It concerns the representation of a planned review instant. It does not certify equipment life, establish an inspection interval or decide when a real asset is safe to use.

Set the supported range before testing the edge

The inspected source and destination both support whole epoch seconds from 1 January 2020 UTC, inclusive, to 1 January 2040 UTC, exclusive. The bridge contract documents that range. Within it, an authorised staff member may record a planned review instant; the business owner determines whether a particular planned date is sensible.

For the boundary rehearsal, record T-38 carries 2147483648 seconds since the Unix epoch. Its intended instant is 19 January 2038 at 03:14:08 UTC. An adjacent record T-37 uses 2147483647, one second earlier. Their distinct references prevent the reviewer from accepting a correct value attached to the wrong record.

The source export shows the right numbers. The receiving T-37 also looks correct, but T-38 appears as 13 December 1901 at 20:45:52 UTC. The gap is far too large to explain as an ordinary local offset, and the exact adjacent-second boundary is a useful clue.

Trace the value through one actual operation

The fictional bridge runs JavaScript and contains this conversion before sending the value onward:

const outgoingSeconds = sourceSeconds | 0;

For Number operands, this bitwise operation uses signed 32-bit integer behaviour. The ECMAScript conversion rules explain the relevant narrowing. It is not a general validation method for timestamps.

The reviewer records the value immediately before and after that line, with the unit and record reference intact:

The original T-38 value fits the agreed application range and is exactly representable as a JavaScript Number. The error is the additional signed-32 conversion. No new interpretation of UTC is needed to explain the result.

A date-only field, a local appointment time without a zone and an instant measured in milliseconds would each require their own contract. This test starts with a fully specified instant in seconds; it must not silently change units or invent a time zone while repairing the numeric path.

Preserve the value and validate what the contract requires

The repair removes the bitwise narrowing. It checks that the incoming value is a finite whole number in the documented interval, then passes that number through the supported receiving representation. A value outside the interval produces an explicit validation result instead of wrapping into an apparently ordinary historical date.

There is no need to enlarge the source or destination's range merely because this bridge used a smaller intermediate representation. Conversely, removing one conversion would be insufficient if the database column or receiving API really had a narrower limit. The team has inspected those boundaries for this fictional integration before selecting the repair.

The operator retains the failed T-38 import evidence and makes a separately identified corrected test run. The source record is unchanged. The corrected run sends 2147483648; the receiving record reads back that same number and displays the intended UTC instant. The reviewer also checks T-37 and T-39, so the accepted result cannot be a special-case substitution for one troublesome value.

Keep meaningful negative controls

The acceptance record includes an ordinary 2026 instant to show that routine records still pass. It includes the start of the supported range and the final whole second before its end. It also tries exactly 1 January 2040 UTC, which is outside the agreed half-open range and must be refused. That refusal is a range decision, not a claim that 2040 dates are universally invalid.

A fractional second is rejected because this particular contract accepts whole seconds. A missing value and a nonnumeric string receive explicit failures. Neither is converted to zero, the current time or an equipment default. An unrelated record T-52 retains its own review instant throughout the rehearsal.

For each accepted record, compare three things: the source number and unit, the destination number and unit, and the displayed instant. Matching formatted dates alone could conceal two compensating conversion mistakes. Matching numbers alone would miss a display that interprets seconds as milliseconds.

Finish the operational handover

The completed repair record names the bridge version, its accepted range and the boundary fixtures. It also says who reviews a later change to the source or destination format. The next maintainer should not reintroduce | 0 as a harmless way to make a number look like an integer.

If staff need local display, add a separate check using the agreed named time zone and explicit test date. Keep the stored instant unchanged and let the presentation show the appropriate local interpretation. That is a later display responsibility; it is not how this century-changing defect was fixed.

The outcome here is specific: three adjacent valid instants survive the bridge, unsupported inputs stop visibly, and an unrelated record remains unchanged. The organisation still owns the real review policy and the professional decisions attached to an asset. A technical conversion test cannot make those decisions for it.

Use the operations application service to discuss the actual equipment and staff workflow. Bring a sanitised source value, the receiving value, their declared units and one neighbouring case to the first conversation.