Changeset 6248497 in Klonkt for test

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:

• test/archive-export.test.js (modified) (1 diff)

test/archive-export.test.js

@@ -175 +175 @@
 });
 
+test('een SQL-tijdstempel wordt als UTC gelezen, niet als lokale tijd', () => {
+  // SQLite schrijft CURRENT_TIMESTAMP in UTC zonder zone erbij. Date.parse leest
+  // die vorm als LOKALE tijd, en dan schuift elk tijdstempel in het archief mee
+  // met de machine die de export draait -- in Amsterdam twee uur.
+  //
+  // Deze test is alleen zinvol onder een NIET-UTC tijdzone; draai hem daarom ook
+  // eens als:  TZ=Europe/Amsterdam node --test test/archive-export.test.js
+  post('tijdstip', { published_at: '2026-07-01 12:56:10', created_at: '2026-07-01 12:56:10' });
+  const o = lees(AX.buildArchive('me'), 'posts/tijdstip.json');
+  assert.equal(o.published, '2026-07-01T12:56:10.000Z',
+    'het moment uit de database is UTC en hoort dat te blijven');
+});
+
 test('een concept gaat gewoon mee', () => {
   post('concept', { status: 'draft', published_at: null });