Convertire ICS in CSV

Un calendario è progettato per guardare avanti, e non per totalizzare a posteriori. Le ore fatturate a un cliente lo scorso trimestre, quante persone sono davanti a una riunione ricorrente, quante stanze sono state usate nei giorni in cui erano prenotate, se un’aula è stata occupata mentre risultava bloccata: nessuna di queste è una vista di un calendario, e tutte quante sono una tabella pivot.

L’esportazione esiste per essere contata. Tenerne conto è ciò che decide quali perdite della conversione sono gravi. Perdere il colore di un evento non è nulla; perdere il fatto che un evento si ripeteva è tutto, ed è l’argomento delle prossime due sezioni.

È la cosa da leggere prima di fidarsi di un totale. Nel formato calendario, una serie ricorrente è un evento con una regola di ripetizione: lo stand-up quotidiano dell’anno scorso è un unico `VEVENT` con un `RRULE` che dice ogni giorno feriale fino a una certa data, più eventualmente qualche `RDATE` aggiuntivo e qualche `EXDATE` per i giorni in cui è stato cancellato.

Le colonne prodotte qui sono le proprietà dell’evento: riepilogo, inizio, fine, luogo, descrizione, organizzatore, stato, identificativo e partecipanti. `RRULE`, `RDATE` ed `EXDATE` non sono fra queste, e la serie contribuisce una sola riga, con gli orari della prima occorrenza. Un trimestre di stand-up è una riga da quindici minuti. Qualsiasi somma sulla colonna delle durate sarà sbagliata per quanto le ricorrenze pesano sul calendario, che nella maggior parte delle agende lavorative è la parte maggiore del tempo.

La soluzione è a monte, ed è meno faticosa di quanto sembri. Sia Google Calendar sia Outlook, quando viene chiesto di esportare o stampare un intervallo di date invece di un intero calendario, emettono le occorrenze singole invece della regola: esportando «questo trimestre» si ottiene un file in cui ogni stand-up è un `VEVENT` distinto e ognuno diventa una riga.

Dove questa opzione non è disponibile, l’espansione è un lavoro da script, non da foglio di calcolo: la libreria `icalendar` di Python con `dateutil.rrule`, oppure `ical-expander` per Node, produce le occorrenze fra due date. In entrambi i casi l’espansione si fa mentre il file è ancora un ICS. Una volta diventato tabella, la regola è persa e nulla può ricostruirla, perché la tabella non l’ha mai contenuta.

Nell’ordine: `riepilogo`, `inizio`, `fine`, `luogo`, `descrizione`, `organizzatore`, `stato`, `identificativo`, `partecipanti`. Ogni evento produce una riga con tutte e nove, vuote dove l’evento non aveva quella proprietà, così la tabella è rettangolare indipendentemente da quanto disomogenea sia la sorgente.

Due meritano attenzione. Lo `stato` distingue eventi confermati, provvisori e cancellati, e quelli cancellati generano comunque una riga: vanno filtrati prima di sommare le durate, altrimenti un workshop annullato verrà contato come tempo trascorso. L’`identificativo` è una stringa stabile assegnata dal calendario, ed è l’unico modo affidabile di deduplicare quando due esportazioni si sovrappongono; ordinarlo e togliere i duplicati è molto più sicuro che tentare di abbinare per riepilogo e ora di inizio.

I timestamp vengono riscritti dalla forma compatta del calendario in ISO 8601, quindi `20260301T080000Z` diventa `2026-03-01T08:00:00Z`, che qualsiasi foglio di calcolo riconosce. Ciò che non viene fatto è uno spostamento fra fusi.

Un valore scritto in UTC mantiene la Z finale. Un valore qualificato da un parametro `TZID`, come `DTSTART;TZID=Europe/Roma:20260301T080000`, è locale in quel fuso, e viene scritto così com’è, `2026-03-01T08:00:00`, senza Z né offset. Convertirlo richiederebbe un database dei fusi orari, e presumere UTC sposterebbe ogni appuntamento di un’ora o più. Il risultato è una colonna in cui alcune celle dichiarano il proprio fuso e altre no, e la tabella non dice in quale fuso fossero le altre. Per sommare durate non è un problema, perché inizio e fine condividono il fuso. Per confrontare orari fra persone in paesi diversi sì, e il fuso va recuperato dal file di origine.

Un evento tutto il giorno è scritto con valori di data anziché timestamp, e nella conversione diventa un semplice `2026-03-01` nelle colonne di inizio e fine, senza la parte dell’ora. È una forma non ambigua e che ordina correttamente, che è più di quanto si possa dire della maggior parte della gestione delle date.

L’insidia è nel formato e non nella conversione: per un valore di data la fine è esclusiva. Un evento di un giorno il 3 è memorizzato con inizio il 3 e fine il 4, e un workshop di tre giorni dal 3 al 5 finisce il 6. Prima di riportare l’intervallo a qualcuno va sottratto un giorno, e va usata cautela con formule che calcolano la durata: l’aritmetica è giusta per il formato e sbagliata per la frase che qualcuno ne ricaverà.

Il formato calendario permette di indicare un inizio e una durata anziché un inizio e una fine, e alcuni software usano sempre questa forma. Qui viene mappata nella colonna solo la proprietà di fine, quindi quegli eventi arrivano con l’inizio valorizzato e la fine vuota.

È un comportamento silenzioso piuttosto che dannoso, ed è facile non notarlo su una tabella grande, perché le celle vuote sembrano dati facoltativi. Se la colonna delle fini è rada, questa è la ragione: ordinando per quella colonna si vede se i vuoti si concentrano su una sola sorgente. Recuperare il valore vuol dire tornare all’ICS e leggere la proprietà di durata, che è un lavoro da script e non da foglio di calcolo.

Un invito memorizza il partecipante come indirizzo nel valore e come nome visualizzato in un parametro. Viene conservata la metà leggibile: la cella contiene «Anna Rossi» dove l’invito portava un nome comune, e `[email protected]` dove non lo portava. Più partecipanti sono uniti con punto e virgola e spazio in una sola cella. L’organizzatore è trattato allo stesso modo, in una colonna dedicata.

È una scelta deliberata rispetto all’inventare `partecipante1` fino a `partecipante9`, che troncherebbe il decimo e lascerebbe nove colonne quasi vuote per tutti gli altri. Contare i partecipanti diventa una formula sulla cella, non un conteggio di colonne: in un foglio di calcolo, la lunghezza della cella meno la lunghezza senza punti e virgola, più uno. Spezzare la cella in righe distinte è un passaggio in Power Query o un mini script se serve una riga per persona.

Il formato calendario porta più degli appuntamenti. I task sono `VTODO`, le note di diario sono `VJOURNAL`, i blocchi di disponibilità sono `VFREEBUSY`, e gli allarmi stanno dentro gli eventi come `VALARM`. Qui si legge solo `VEVENT`.

Un file composto solo da task quindi termina con «Nessun evento del calendario trovato in questo file», che è preciso e non un errore: un’esportazione da un’app di promemoria non è un calendario di eventi anche se condivide l’estensione. Allarmi, allegati e lo stato di risposta dei singoli partecipanti sono scartati dagli eventi letti, per la stessa ragione per cui lo è la ricorrenza: una tabella non ha una forma per ospitarli, e inventare colonne sarebbe peggio che ometterli.

Importare, non aprire. In Excel, Dati → Da testo/CSV, e impostare le colonne di inizio e fine come Testo prima del caricamento, a meno che non si voglia che Excel le reinterpreti: la sua lettura delle date toglie volentieri l’offset, riformatta secondo la lingua del computer, e trasforma una stringa ISO in qualcosa che non ordina più come testo. Anche la colonna dell’identificativo andrebbe tenuta come Testo.

Le descrizioni sono l’altro punto da controllare. Le descrizioni delle riunioni contengono abitualmente virgole, virgolette e ritorni a capo veri: un’agenda incollata, un blocco di numeri di telefono. Tutti e tre sono gestiti racchiudendo il valore fra virgolette e raddoppiando le virgolette interne, che è la convenzione RFC 4180 letta da qualunque importer serio. Una divisione ingenua su virgola in una pipeline di shell non lo fa, quindi meglio usare un vero lettore CSV o convertire in TSV.