Titel, locatie, datum en tijd, tijdzone, herhaling, genodigden, meldingen en notities — download daarna het .ics-bestand of open het direct in je agenda. Je kunt ook een planning plakken of een document of foto toevoegen om meerdere evenementen tegelijk te maken.
Waarom klopt mijn agenda-item een uur, of een dag, niet?
Een .ics-bestand kan een tijd op drie manieren weergeven, en bijna altijd is de verkeerde de oorzaak. Een zwevende tijd (DTSTART:20260815T090000, zonder zone) is negen uur, waar het ook wordt geopend. Een UTC-tijd (een afsluitende Z) is één absoluut moment. Een benoemde zone (DTSTART;TZID=Europe/London:...) is een moment dat op dezelfde lokale kloktijd blijft staan, ook bij de overgang naar zomer- of wintertijd. Een import die een uur verschilt, komt meestal door een Windows-achtige zonenaam zoals 'GMT Standard Time' die de lezende agenda niet herkent en dan terugvalt op UTC; een dagvullende gebeurtenis die een dag verschuift, komt meestal door een tijdstempel op middernacht waar VALUE=DATE nodig was, of door een einddatum die op de laatste dag zelf staat in plaats van de dag erna, omdat DTEND exclusief is. ICS Maker schrijft standaard een zwevende tijd, en een TZID met een IANA-zonenaam wanneer er een wordt gekozen — zonder meegeleverd VTIMEZONE-blok, dat elke gangbare agenda toch al afleidt uit de zonenaam zelf.
De drie manieren waarop een bestand een tijdstip kan aangeven
- Zwevend — helemaal geen zone
DTSTART:20260815T090000. Negen uur 's ochtends, waar het ook wordt geopend. Juist voor een lokale afspraak, een herinnering, of iets dat wordt bepaald door de klok van de lezer zelf; fout zodra twee mensen in verschillende landen elkaar op hetzelfde moment moeten treffen.- UTC — een absoluut moment
DTSTART:20260815T090000Z, met de afsluitendeZ. Eén moment in de tijd, omgezet naar lokale tijd door wat het ook opent. Ondubbelzinnig, maar het verliest het gegeven dat de afspraak “tien uur in Londen” was, dus een overgang naar zomer- of wintertijd verschuift het.- Benoemde zone — een moment dat de overgang naar zomer- of wintertijd overleeft
DTSTART;TZID=Europe/London:20260815T090000. Wat een terugkerende afspraak nodig heeft: de reeks blijft om tien uur lokale tijd, ook al verschuift de offset eronder. RFC 5545 vraagt om een bijbehorendVTIMEZONE-blok dat de offsets van die zone ernaast definieert.
Deze builder schrijft standaard de eerste, en de derde wanneer u een zone uit de lijst kiest. Die standaardinstelling is bewust: een tandartsafspraak om negen uur moet om negen uur zijn, en de zone toevoegen van welke machine het bestand toevallig heeft gemaakt, is hoe een item een uur verkeerd uitkomt voor wie het leest.
Het schrijft de TZID zonder meegeleverd VTIMEZONE-blok, wat de moeite waard is om te weten voordat u het bestand ergens ongebruikelijks naartoe stuurt. Apple Calendar, Google Calendar, Outlook en Thunderbird hebben allemaal de IANA-tijdzonedatabase aan boord en leiden Europe/London alleen al af uit de naam, dus het blok zou enkele honderden regels zijn die herhalen wat de lezer al weet. Een strikte parser die alleen de zones herkent die in het bestand zelf zijn gedefinieerd, is het geval waarin die afweging niet uitpakt — plak dan handmatig een VTIMEZONE-blok erin als u er een aan het voeden bent.
Een bestand lezen dat verkeerd is aangekomen
Open het in een teksteditor en kijk naar de DTSTART-regel, want het antwoord staat daar altijd. Een afsluitende Z met een offset die u niet verwachtte, betekent dat de afzender heeft omgezet naar UTC vanuit een zone die u niet deelt. Een TZID met een naam als GMT Standard Time in plaats van Europe/London is de spelling van Microsoft Exchange, en agenda's die alleen de IANA-namen kennen, vallen dan mogelijk terug op UTC — dat is het klassieke geval van een import die een uur verkeerd uitkomt. Een TZID met een zonenaam die noch een IANA-naam is, noch is gedefinieerd door een VTIMEZONE-blok in hetzelfde bestand, is het geval waarbij elke lezer er anders naar raadt, en vaak genoeg naar UTC raadt om het als tweede te controleren.
De dagvullende gebeurtenis die een dag opschuift
Een dagvullende gebeurtenis is een datum, geen tijd: DTSTART;VALUE=DATE:20260815. Als het in plaats daarvan als een tijdstempel op middernacht wordt geschreven, wordt het een echt moment, en elke omzetting westwaarts trekt het naar de vorige dag. De einddatum is de andere helft van de valkuil — die is exclusief, dus één dag op de 15e eindigt op de 16e, en een bestand dat het op de 15e laat eindigen, toont in sommige agenda's helemaal niets.
Vragen
- Waarom klopt mijn agenda-item een uur niet?
- Bijna altijd een verschil door de zomer-/wintertijd: het bestand noemt een vaste UTC-offset, of een Windows-achtige zonenaam die de lezende agenda niet herkent, waarna de lezer terugvalt op UTC. Controleer de DTSTART-regel — als die eindigt op Z, is de tijd absolute UTC, en als er een TZID bij staat, moet die zone gespeld zijn als een IANA-naam zoals Europe/Paris, of anders zijn gedefinieerd door een VTIMEZONE-blok in hetzelfde bestand. Gangbare agenda's leiden de IANA-naam af uit hun eigen kopie van de tijdzonedatabase en hebben zo'n blok niet nodig.
- Moet ik een tijdzone instellen of weglaten?
- Laat hem weg wanneer de gebeurtenis wordt bepaald door de lokale kloktijd — een afspraak, een herinnering, een les die om negen uur begint, waar u ook bent. Stel er een in wanneer de gebeurtenis op één moment plaatsvindt dat gasten in andere zones moeten omrekenen, zoals een gesprek, een webinar, of een uitzending.
- Wat is een zwevende tijd?
- Een datum-tijd geschreven zonder zone en zonder afsluitende Z, die volgens RFC 5545 moet worden geïnterpreteerd als lokale tijd waar hij ook wordt gelezen. Het is vaker de juiste keuze dan mensen verwachten, en de verkeerde zodra twee lezers in verschillende zones het over hetzelfde moment eens moeten worden.
- Waarom staat mijn dagvullende gebeurtenis op de verkeerde dag?
- Omdat hij is geschreven als een tijdstempel op middernacht in plaats van als een datumwaarde. Een echte dagvullende gebeurtenis gebruikt VALUE=DATE zonder enige tijd, dus er valt niets om te zetten. Onthoud ook dat de einddatum exclusief is: een eendaagse gebeurtenis op de 15e heeft DTEND op de 16e.