P2-15: datumweergave dd-MM-yyyy HH:mm, API-datums direct uit datePicked; Drupal-tijdzonepatch als snippet

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

TASKS.md

@@ -287,7 +287,7 @@ want `datum` bevat er geen.
 
 ### 🤝 CLAUDE KAN DIT OVERNEMEN — zeg het en het gebeurt
 
-**P2-15 · ✅ de live indiening is GEDAAN (2026-09-13, nid 217916, Enkhuizen) — zie P2-15 verderop voor de 2 bevindingen (tijd +2u = Drupal, rauwe datumweergave = builder).** ~~het enige dat nog rest voor "uitgaansevenement
+**P2-15 · ✅ live indiening GEDAAN (2026-09-13, nid 217916, Enkhuizen, door Bob verwijderd); rauwe datumweergave gefixt. Rest voor Bob: tijd +2u aan de Drupal-kant, patch in `snippets/drupal-datum-tijdzone.md`.** ~~het enige dat nog rest voor "uitgaansevenement
 aanmaken". Eén evenement echt indienen en de node terugvinden op de site.
 Claude kan dit op de emulator doen (de sessie is ingelogd, de zaak staat
 voorgeselecteerd), **maar de node komt direct gepubliceerd op de live site** —
@@ -4661,7 +4661,14 @@ DateTimeZone('Europe/Amsterdam'))` → naar UTC), of afspreken dat de app UTC
 stuurt. Drupal-kant is netter: dan blijven oudere/andere clients ook goed.
 Geldt vermoedelijk ook voor `stadsactiviteiten/create`.
 
-**Bevinding 2 — cosmetisch (builder) — Claude bezig 2026-09-13 ±20:45:** het Datum-veld toont
+**Bevinding 2 — ✅ AFGEROND 2026-09-13 (Claude, builder, exportgeverifieerd,
+`dart analyze` 0 errors).** Beide datumvelden tonen nu `dd-MM-yyyy HH:mm` (Set
+Form Field → DateTime Format → Custom), en de argumenten `datumStart`/`datumEind`
+van `evenementCreate` hangen rechtstreeks aan `datePicked1`/`datePicked2` met
+format `yyyy-MM-dd HH:mm:ss` — de API krijgt dus exact dezelfde string als
+vóór deze wijziging; `datumVoorApi` wordt op deze pagina niet meer gebruikt.
+Nog niet live nagetest (zou een nieuwe testnode kosten); de gegenereerde code
+is 1-op-1 gecontroleerd. *Oorspronkelijk:* het Datum-veld toont
 na kiezen de rauwe `2026-09-25 20:20:00.000`. De Text-binding van dat veld
 door een `dateTimeFormat` halen (bv. `d MMM yyyy, HH:mm`) — alleen de weergave,
 `datumVoorApi` blijft de bron voor het verzenden.

snippets/drupal-datum-tijdzone.md

@@ -0,0 +1,55 @@
+# Tijdzone-fix voor `evenementen/create` en `stadsactiviteiten/create` (Drupal 7, custom.module)
+
+**Symptoom (gemeten 2026-09-13, nid 217916):** de app stuurt
+`"datum_start":"2026-09-25 20:20:00"` (lokale Nederlandse tijd), de site toont
+**22:20**. Drupal leest de string als UTC en rendert in Europe/Amsterdam.
+
+**Fix — in `custom.evenementen_aanmaken.inc`, op de plek waar `datum_start`
+(en `datum_eind`) naar `field_date` gaat.** Interpreteer de binnenkomende
+string expliciet als Amsterdamse tijd en sla 'm als UTC op (Date-veld met
+`timezone_db = UTC`, de gebruikelijke instelling):
+
+```php
+/**
+ * Zet een lokale (Europe/Amsterdam) datumstring om naar de UTC-string die
+ * een Date-veld met timezone_db = 'UTC' verwacht.
+ */
+function _custom_lokaal_naar_utc($s) {
+  $s = trim($s);
+  if ($s === '') {
+    return '';
+  }
+  try {
+    $d = new DateTime($s, new DateTimeZone('Europe/Amsterdam'));
+  }
+  catch (Exception $e) {
+    return $s; // ongeldig formaat: laat de bestaande validatie het afvangen
+  }
+  $d->setTimezone(new DateTimeZone('UTC'));
+  return $d->format('Y-m-d H:i:s');
+}
+```
+
+en dan waar de waarde gezet wordt (naam van de variabelen kan afwijken):
+
+```php
+$start = _custom_lokaal_naar_utc($data['datum_start']);
+$eind  = !empty($data['datum_eind']) ? _custom_lokaal_naar_utc($data['datum_eind']) : $start;
+$node->field_date[LANGUAGE_NONE][0]['value']  = $start;
+$node->field_date[LANGUAGE_NONE][0]['value2'] = $eind;
+$node->field_date[LANGUAGE_NONE][0]['timezone'] = 'Europe/Amsterdam';
+$node->field_date[LANGUAGE_NONE][0]['timezone_db'] = 'UTC';
+```
+
+**Controleer eerst** hoe het veld is ingesteld: `timezone_db` van
+`field_date` (Structure → Content types → Evenement → field_date → "Time zone
+handling"). Staat die op *"No time zone conversion"* / `timezone_db = ''`, dan
+is de fix juist omgekeerd: dan moet de string ongewijzigd opgeslagen worden en
+zit de +2u in de *weergave* (views-datumformat met tijdzone).
+
+**Verificatie:** één testevenement indienen met 20:20 en in
+`flutterflow_events.json?nid=<nid>` moet `datum` op `20:20` uitkomen. Dezelfde
+route geldt voor `stadsactiviteiten/create` (zelfde helper hergebruiken).
+
+**Aan de app-kant is niets nodig** — die stuurt bewust lokale tijd; als je hier
+UTC gaat verwachten, moet `datumVoorApi`/de Date-Format-binding in de app mee.