From 663b8756a6403689472888b36f8e958dc201bf46 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marc-Andr=C3=A9=20Bombeck?= Date: Thu, 22 Oct 2026 00:40:08 +0200 Subject: [PATCH] docs(import): say why lab CSV duplicates are cut on the read zone's day A wall-clock time read in another zone on a retry is a different instant, so neither an exact-instant match nor the zone's day catches it near midnight, and widening the match would drop a genuine reading of the same value on the neighbouring day. The earlier import's zone is not stored, so the comment states the rule that never loses a reading. --- src/lib/import/labs-csv.ts | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/lib/import/labs-csv.ts b/src/lib/import/labs-csv.ts index e3308503a..92ec2e998 100644 --- a/src/lib/import/labs-csv.ts +++ b/src/lib/import/labs-csv.ts @@ -378,6 +378,18 @@ export async function importLabsCsv(args: { } // 2. Duplicates against the record, one query for the chunk. + // + // The day is cut in the zone the file is read in. Only a reading with a + // wall-clock time depends on it: a date alone is stored at the noon-UTC + // anchor and a time with an offset is one instant, and both land on the + // same day in every zone. A wall-clock time read in another zone on a + // retry is a different instant, and near midnight a different day, so it + // can be written twice. Matching on the exact instant would not catch it + // (the instant moved with the zone), and widening the match by the zone + // difference would also swallow a genuine reading of the same value on + // the neighbouring day. The zone the earlier import read the file in is + // not stored, so the record cannot tell those two apart; the day in the + // current zone is the one rule that never drops a real reading. const days = planned .map((p) => labReadingDay(p.row.takenAt, timezone)) .sort();