Changeset 6248497 in Klonkt for src/services/ArchiveExportService.js

Timestamp:

08/07/2026 04:37:37 PM (5 weeks ago)

Author:

roboburr <roboburr@…>

Branches:

main

Children:

a4fea5e

Parents:

7d7b36d

git-author:

roboburr <roboburr@…> (08/07/2026 04:37:26 PM)

git-committer:

roboburr <roboburr@…> (08/07/2026 04:37:37 PM)

Message:

Export en import kiezen de juiste instance, en tijdstempels zijn echt UTC

Twee fouten, allebei op productie gevonden en allebei van het soort dat SUCCES
meldt.

## 1. Het script opende de verkeerde database

Op een split install deelt elke Klonkt de code in /opt/klonkt maar staat zijn data
onder /var/lib/klonkt/<slug>/ met een eigen .env. De scripts lazen die .env niet,
dus database.js viel terug op storage/database.sqlite IN DE CODE-MAP. Op een
server die ooit de enkelvoudige opzet draaide ligt daar een achtergebleven oude
database.

Waargenomen: export-archive.mjs boiert schreef een archief van 444 bytes met
"posts: 0" en meldde dat het gelukt was, terwijl het in een oude lege database
keek. liz en sood gaven "onbekende site". Het script raakte die oude database
ook nog aan (boot-migraties), terwijl het alleen hoort te lezen.

Nu leest scripts/instance-env.mjs de .env van de instance (standaard
/var/lib/klonkt/<slug>/.env, of --data-root / --env) VOORDAT de service geladen
wordt -- database.js opent de database namelijk bij import. De uitvoer noemt
voortaan welke .env en welke database gebruikt zijn.

En zonder PUBLIC_BASE_URL stopt hij nu HARD in plaats van het als bijzin te
melden: zonder origin krijgt het archief een lege origin, en dan maakt een import
nieuwe AP-ids. Dan is het een kopie van de tekst en geen herstel -- precies de
belofte waar het formaat om draait.

Voor de importer weegt dit zwaarder dan voor de exporter: in de verkeerde
database schrijven draai je niet terug.

## 2. Tijdstempels schoven met de tijdzone van de machine

Vraag van Bart: normaliseert de export wel naar UTC? Nee.

SQLite schrijft CURRENT_TIMESTAMP als "2026-07-01 12:56:10" -- in UTC, maar zonder
zone. Date.parse leest die vorm als LOKALE tijd. Op een machine in Amsterdam komt
daar 10:56:10Z uit: twee uur verschoven, in elk archief.

Geen enkele test kon dat zien, want de testmachine draait op UTC. En mijn eigen
rondgang-vergelijking plakte er zelf een Z achter, waarmee ik er precies overheen
keek.

toISO leest een zoneloze vorm nu expliciet als UTC. Nieuwe test die alleen onder
een niet-UTC zone iets bewijst; gecontroleerd dat hij onder Europe/Amsterdam
omvalt zonder de fix. Hele suite 577/577 onder zowel UTC als Europe/Amsterdam.

File:

• src/services/ArchiveExportService.js (modified) (1 diff)

src/services/ArchiveExportService.js

@@ -38 +38 @@
 
 const sha256 = (buf) => crypto.createHash('sha256').update(buf).digest('hex');
-const toISO = (d) => { const t = Date.parse(d); return isNaN(t) ? null : new Date(t).toISOString(); };
+/**
+ * Naar ISO 8601 in UTC.
+ *
+ * SQLite schrijft CURRENT_TIMESTAMP als "2026-07-01 12:56:10" -- in UTC, maar
+ * ZONDER zone erbij. Date.parse leest die vorm als LOKALE tijd, en dan schuift
+ * elk tijdstempel in het archief mee met de tijdzone van de machine die de export
+ * draait. Op een server in Amsterdam is dat twee uur, en dat merk je pas als je
+ * ergens anders importeert.
+ *
+ * Gevonden doordat Bart vroeg of dit wel naar UTC normaliseert. De testmachine
+ * draait op UTC, dus geen enkele test kon het zien.
+ */
+const toISO = (d) => {
+  if (!d) return null;
+  const s = String(d).trim();
+  const zonderZone = /^\d{4}-\d{2}-\d{2}[ T]\d{2}:\d{2}(:\d{2}(\.\d+)?)?$/.test(s);
+  const t = Date.parse(zonderZone ? `${s.replace(' ', 'T')}Z` : s);
+  return isNaN(t) ? null : new Date(t).toISOString();
+};
 
 const MIME_BY_EXT = {