Changeset 6248497 in Klonkt

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.

Files:

• docs/EXPORT-FORMAT.md (modified) (1 diff)
• scripts/export-archive.mjs (modified) (3 diffs)
• scripts/import-archive.mjs (modified) (2 diffs)
• scripts/instance-env.mjs (added)
• src/services/ArchiveExportService.js (modified) (1 diff)
• test/archive-export.test.js (modified) (1 diff)

docs/EXPORT-FORMAT.md

@@ -99 +99 @@
 | `summary` | `posts.content_warning` | AS2 summary is the content warning |
 | `sensitive` | `posts.nsfw` | |
-| `published` | `posts.published_at` ?? `created_at` | ISO 8601, UTC. Klonkt stores timestamps in two spellings (`YYYY-MM-DD HH:MM:SS` and full ISO); the archive normalises to ISO. The **instant** survives a round trip, the spelling does not. |
+| `published` | `posts.published_at` ?? `created_at` | ISO 8601, UTC. SQLite writes `CURRENT_TIMESTAMP` in UTC but without a zone, and `Date.parse` reads that shape as *local* time — so a timezone-less value is explicitly read as UTC before conversion. Klonkt stores timestamps in two spellings (`YYYY-MM-DD HH:MM:SS` and full ISO); the archive normalises to ISO. The **instant** survives a round trip, the spelling does not. |
 | `updated` | `posts.updated_at` | omitted when equal to `published` |
 | `url` | `<origin>/<slug>` | the human permalink |

scripts/export-archive.mjs

@@ -6 +6 @@
 //     node scripts/export-archive.mjs <slug> --out boiert.zip
 //     node scripts/export-archive.mjs <slug> --dir ./archief
+//
+// Op een machine met meerdere instances leest hij de .env van die instance zelf
+// (standaard /var/lib/klonkt/<slug>/.env). Dat is niet netjesheid maar noodzaak:
+// zonder die .env opent hij de database die toevallig in de code-map ligt, en op
+// een server die ooit de enkelvoudige opzet draaide is dat een oude lege. Dan
+// komt er een archief uit dat MELDT dat het gelukt is en nul posts bevat.
+//
+//     --data-root <map>   waar de instances staan (standaard /var/lib/klonkt)
+//     --env <pad>         een .env rechtstreeks aanwijzen
 //
 // Het formaat staat in docs/EXPORT-FORMAT.md.
@@ -15 +24 @@
 import fs from 'fs';
 import path from 'path';
-import { buildArchive, zipArchive, writeArchiveDir } from '../src/services/ArchiveExportService.js';
+import { kiesInstance, eisOrigin } from './instance-env.mjs';
 
 const args = process.argv.slice(2);
@@ -22 +31 @@
 
 if (!slug) {
-  console.error('gebruik: node scripts/export-archive.mjs <slug> [--dry-run | --out <zip> | --dir <map>]');
+  console.error('gebruik: node scripts/export-archive.mjs <slug> [--data-root <map>] [--env <pad>] [--dry-run | --out <zip> | --dir <map>]');
   process.exit(1);
 }
 
-const uit = buildArchive(slug);
+// EERST de instance kiezen, DAN pas de service laden: src/config/database.js
+// leest DATABASE_PATH bij import en opent de database meteen.
+let gekozen;
+try {
+  gekozen = kiesInstance(slug, {
+    dataRoot: typeof vlag('--data-root') === 'string' ? vlag('--data-root') : null,
+    envPad: typeof vlag('--env') === 'string' ? vlag('--env') : null,
+  });
+} catch (e) { console.error(e.message); process.exit(1); }
+eisOrigin(gekozen.bron);
+
+const { buildArchive, zipArchive, writeArchiveDir } = await import('../src/services/ArchiveExportService.js');
+
+let uit;
+try { uit = buildArchive(slug); }
+catch (e) {
+  console.error(`${e.message}`);
+  if (gekozen.bron) console.error(`(gelezen uit ${gekozen.bron})`);
+  else console.error('(geen instance-.env gevonden -- op een split install: --data-root /var/lib/klonkt)');
+  process.exit(1);
+}
 const t = uit.counts;
-console.log(`site      : ${uit.manifest.site.slug} (${uit.manifest.origin || 'geen PUBLIC_BASE_URL'})`);
+console.log(`site      : ${uit.manifest.site.slug} (${uit.manifest.origin})`);
+console.log(`instellingen uit: ${gekozen.bron || 'de omgeving'}`);
+console.log(`database  : ${process.env.DATABASE_PATH || '(standaard in de code-map)'}`);
 console.log(`posts     : ${t.posts}`);
 console.log(`antwoorden: ${t.replies}   (alleen-lezen archief)`);

scripts/import-archive.mjs

@@ -17 +17 @@
 // en hoort een aparte, bewuste actie te zijn.
 
-import { readArchive, importArchive } from '../src/services/ArchiveImportService.js';
+import { kiesInstance, eisOrigin } from './instance-env.mjs';
 
 const args = process.argv.slice(2);
@@ -24 +24 @@
 
 if (!slug || !bron) {
-  console.error('gebruik: node scripts/import-archive.mjs <slug> <archief.zip|map> [--dry-run] [--overwrite]');
+  console.error('gebruik: node scripts/import-archive.mjs <slug> <archief.zip|map> [--data-root <map>] [--env <pad>] [--dry-run] [--overwrite]');
   process.exit(1);
 }
+
+// EERST de instance kiezen, DAN pas de service laden -- database.js opent de
+// database bij import. Bij een IMPORT weegt dit zwaarder dan bij een export: in
+// de verkeerde database schrijven is niet terug te draaien.
+const vlag = (naam) => { const i = args.indexOf(naam); return i >= 0 ? (args[i + 1] || null) : null; };
+let gekozen;
+try {
+  gekozen = kiesInstance(slug, { dataRoot: vlag('--data-root'), envPad: vlag('--env') });
+} catch (e) { console.error(e.message); process.exit(1); }
+eisOrigin(gekozen.bron);
+console.log(`instellingen uit: ${gekozen.bron || 'de omgeving'}`);
+console.log(`database        : ${process.env.DATABASE_PATH || '(standaard in de code-map)'}`);
+
+const { readArchive, importArchive } = await import('../src/services/ArchiveImportService.js');
 
 let files;

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 = {

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 });