Titolo, luogo, data e ora, fuso orario, ripetizione, invitati, avvisi e note; poi scarica il file .ics o aprilo direttamente nel calendario. Puoi anche incollare un programma o allegare un documento o una foto per creare più eventi insieme.
Perché il mio evento di calendario è sfasato di un'ora, o di un giorno?
Un file .ics può esprimere un orario in tre modi, e quasi sempre la causa è l'uso di quello sbagliato. Un orario mobile (DTSTART:20260815T090000, senza fuso) corrisponde alle nove del mattino ovunque venga aperto. Un orario UTC (con una Z finale) è un istante assoluto. Un fuso con nome (DTSTART;TZID=Europe/London:...) è un istante che resta allo stesso orario locale anche durante i cambi dell'ora legale. Un'importazione sfasata di un'ora è di solito dovuta a un nome di fuso in stile Windows come 'GMT Standard Time', che il calendario di lettura non riconosce e per cui ricade su UTC; un evento per l'intera giornata sfasato di un giorno è di solito dovuto a un timestamp a mezzanotte dove sarebbe servito VALUE=DATE, oppure a una data di fine scritta sull'ultimo giorno anziché sul giorno successivo, dato che DTEND è esclusivo. ICS Maker scrive di default un orario mobile, e un TZID che nomina un fuso IANA quando ne viene scelto uno — senza un blocco VTIMEZONE incorporato, che ogni calendario più diffuso risolve a partire dal nome del fuso stesso.
I tre modi in cui un file può indicare il quando
- Mobile — nessun fuso orario
DTSTART:20260815T090000. Le nove del mattino ovunque venga aperto. Corretto per un appuntamento locale, un promemoria, o qualsiasi cosa definita dall'orologio di chi legge; sbagliato nel momento in cui due persone in paesi diversi devono incontrarsi.- UTC — un istante assoluto
DTSTART:20260815T090000Z, con laZfinale. Un unico momento nel tempo, convertito in ora locale da qualunque programma lo apra. Inequivocabile, ma perde il fatto che la riunione fosse "alle dieci a Londra", quindi un cambio dell'ora legale la sposta.- Fuso con nome — un istante che sopravvive all'ora legale
DTSTART;TZID=Europe/London:20260815T090000. Ciò che serve a una riunione ricorrente: la serie resta alle dieci in orario locale anche mentre lo scarto orario cambia sotto di essa. L'RFC 5545 richiede un bloccoVTIMEZONEcorrispondente che definisca gli scarti orari di quel fuso accanto ad esso.
Questo strumento scrive il primo per impostazione predefinita e il terzo quando scegli un fuso dall'elenco. Questa scelta predefinita è intenzionale: un appuntamento dal dentista alle nove deve restare alle nove, e allegare il fuso orario della macchina che ha generato il file è il modo in cui un evento finisce per essere sfasato di un'ora per chi lo legge.
Scrive il TZID senza un blocco VTIMEZONE incorporato, cosa utile da sapere prima di inviare il file altrove in contesti non comuni. Apple Calendar, Google Calendar, Outlook e Thunderbird includono tutti il database dei fusi orari IANA e risolvono Europe/London a partire dal solo nome, quindi il blocco sarebbe di alcune centinaia di righe che ripetono ciò che chi legge già conosce. Un parser rigoroso che risolve solo i fusi definiti all'interno del file stesso è il caso in cui questa scelta non conviene — incolla a mano un blocco VTIMEZONE se stai alimentando un parser di questo tipo.
Leggere un file arrivato sbagliato
Aprilo in un editor di testo e guarda la riga DTSTART, perché la risposta è sempre lì. Una Z finale con uno scarto orario che non ti aspettavi significa che il mittente ha convertito in UTC da un fuso che non condividi. Un TZID che nomina qualcosa come GMT Standard Time anziché Europe/London è la dicitura di Microsoft Exchange, e i calendari che conoscono solo i nomi IANA possono ricadere su UTC — che è la classica importazione sfasata di un'ora. Un TZID che nomina un fuso che non è né un nome IANA né definito da un blocco VTIMEZONE nello stesso file è il caso in cui ogni programma di lettura tira a indovinare in modo diverso, e indovina UTC abbastanza spesso da essere la seconda cosa da controllare.
L'evento per l'intera giornata che si sposta di un giorno
Un evento per l'intera giornata è una data, non un orario: DTSTART;VALUE=DATE:20260815. Scritto invece come timestamp a mezzanotte, diventa un istante reale, e qualsiasi conversione verso ovest lo trascina nel giorno precedente. La data di fine è l'altra metà della trappola — è esclusiva, quindi un singolo giorno il 15 termina il 16, e un file che lo fa terminare il 15 non mostra nulla in alcuni calendari.
Domande
- Perché il mio evento di calendario è sfasato di un'ora?
- Quasi sempre una discordanza legata all'ora legale: il file indica uno scarto UTC fisso, oppure un nome di fuso in stile Windows che il calendario di lettura non riconosce, e chi legge ricade su UTC. Controlla la riga DTSTART — se termina con Z l'orario è UTC assoluto, e se porta un TZID quel fuso deve essere scritto come nome IANA tipo Europe/Paris, oppure essere definito da un blocco VTIMEZONE nello stesso file. I calendari più diffusi risolvono il nome IANA a partire dalla propria copia del database dei fusi orari e non hanno bisogno di tale blocco.
- Devo impostare un fuso orario o lasciarlo vuoto?
- Lascialo vuoto quando l'evento è definito dall'orario locale — un appuntamento, un promemoria, una lezione che inizia alle nove ovunque tu sia. Impostane uno quando l'evento avviene in un istante unico che gli ospiti in altri fusi devono convertire, come una chiamata, un webinar o una trasmissione.
- Cos'è un orario mobile?
- Una data-ora scritta senza fuso e senza Z finale, che l'RFC 5545 stabilisce debba essere interpretata come orario locale ovunque venga letta. È la scelta giusta più spesso di quanto si pensi, e quella sbagliata ogni volta che due lettori in fusi diversi devono concordare un momento.
- Perché il mio evento per l'intera giornata compare nel giorno sbagliato?
- Perché è stato scritto come timestamp a mezzanotte anziché come valore di data. Un vero evento per l'intera giornata usa VALUE=DATE senza alcun orario, quindi non c'è nulla da convertire. Ricorda anche che la data di fine è esclusiva: un evento di un giorno il 15 ha DTEND il 16.