Título, local, data e hora, fuso horário, repetição, convidados, alertas e notas — depois descarregue o ficheiro .ics ou abra-o diretamente no calendário. Também pode colar uma agenda ou anexar um documento ou uma fotografia para criar vários eventos de uma vez.
Por que meu evento de calendário está uma hora, ou um dia, errado?
Um arquivo .ics pode expressar um horário de três formas, e a errada é quase sempre a causa. Um horário flutuante (DTSTART:20260815T090000, sem fuso) é nove horas onde quer que seja aberto. Um horário UTC (um Z ao final) é um instante absoluto. Um fuso nomeado (DTSTART;TZID=Europe/London:...) é um instante que permanece no mesmo horário local do relógio durante o horário de verão. Uma importação uma hora errada geralmente é um nome de fuso no estilo Windows, como 'GMT Standard Time', que o calendário de leitura não reconhece e usa UTC como alternativa; um evento de dia inteiro um dia errado geralmente é um carimbo de data/hora de meia-noite onde era necessário VALUE=DATE, ou uma data de término escrita no último dia em vez do dia seguinte, já que DTEND é exclusivo. O ICS Maker escreve um horário flutuante por padrão e um TZID nomeando um fuso IANA quando um é escolhido — sem um bloco VTIMEZONE incluído, que todo calendário popular resolve a partir do próprio nome do fuso.
As três formas de um arquivo dizer quando
- Flutuante — sem fuso algum
DTSTART:20260815T090000. Nove da manhã onde quer que seja aberto. Certo para um compromisso local, um lembrete, ou qualquer coisa definida pelo próprio relógio de quem lê; errado no momento em que duas pessoas em países diferentes precisam se encontrar.- UTC — um instante absoluto
DTSTART:20260815T090000Z, com oZao final. Um momento no tempo, convertido para o horário local por quem quer que o abra. Inequívoco, mas perde o fato de que a reunião era "dez horas em Londres", então uma mudança de horário de verão o desloca.- Fuso nomeado — um instante que sobrevive ao horário de verão
DTSTART;TZID=Europe/London:20260815T090000. O que uma reunião recorrente quer: a série permanece às dez horas no horário local mesmo quando o deslocamento muda por baixo dela. A RFC 5545 pede um blocoVTIMEZONEcorrespondente, definindo os deslocamentos daquele fuso junto com ele.
Este construtor escreve a primeira opção por padrão e a terceira quando você escolhe um fuso na lista. Esse padrão é deliberado: uma consulta ao dentista às nove deve ser às nove, e anexar o fuso da máquina que por acaso gerou o arquivo é como um evento acaba uma hora errado para quem o lê.
Ele escreve o TZID sem um bloco VTIMEZONE incluído, o que vale a pena saber antes de enviar o arquivo para algum lugar incomum. Apple Calendar, Google Calendar, Outlook e Thunderbird carregam o banco de dados de fusos horários IANA e resolvem Europe/London apenas pelo nome, então o bloco seria várias centenas de linhas reafirmando o que quem lê já sabe. Um analisador rígido que resolve apenas os fusos definidos no próprio arquivo é o caso em que essa escolha não compensa — cole um bloco VTIMEZONE manualmente se estiver alimentando um desses.
Lendo um arquivo que chegou errado
Abra-o em um editor de texto e observe a linha DTSTART, porque a resposta está sempre ali. Um Z ao final com um deslocamento que você não esperava significa que o remetente converteu para UTC a partir de um fuso que você não compartilha. Um TZID nomeando algo como GMT Standard Time em vez de Europe/London é a grafia do Microsoft Exchange, e calendários que só conhecem os nomes IANA podem usar UTC como alternativa — que é a clássica importação uma hora errada. Um TZID nomeando um fuso que não é nem um nome IANA nem definido por um bloco VTIMEZONE no mesmo arquivo é o caso em que cada leitor supõe algo diferente, e supõe UTC com frequência suficiente para que seja a segunda coisa a verificar.
O evento de dia inteiro que se move um dia
Um evento de dia inteiro é uma data, não um horário: DTSTART;VALUE=DATE:20260815. Escrito como um carimbo de data/hora de meia-noite em vez disso, ele se torna um instante real, e qualquer conversão para o oeste o arrasta para o dia anterior. A data de término é a outra metade da armadilha — ela é exclusiva, então um único dia no dia 15 termina no dia 16, e um arquivo que o termina no dia 15 não mostra nada em alguns calendários.
Perguntas
- Por que meu evento de calendário está uma hora errado?
- Quase sempre uma incompatibilidade de horário de verão: o arquivo nomeia um deslocamento UTC fixo, ou um nome de fuso no estilo Windows que o calendário de leitura não reconhece, e quem lê usa UTC como alternativa. Verifique a linha DTSTART — se terminar em Z, o horário é UTC absoluto, e se tiver um TZID, esse fuso precisa estar escrito como um nome IANA como Europe/Paris, ou então ser definido por um bloco VTIMEZONE no mesmo arquivo. Calendários populares resolvem o nome IANA a partir da própria cópia do banco de dados de fusos horários e não precisam de tal bloco.
- Devo definir um fuso horário ou deixá-lo em branco?
- Deixe em branco quando o evento for definido pelo horário local do relógio — um compromisso, um lembrete, uma aula que começa às nove onde quer que você esteja. Defina um quando o evento acontecer em um único instante que convidados em outros fusos precisem converter, como uma chamada, um webinar ou uma transmissão.
- O que é um horário flutuante?
- Uma data-hora escrita sem fuso e sem Z ao final, que a RFC 5545 diz que deve ser interpretada como horário local onde quer que seja lida. É a escolha certa com mais frequência do que as pessoas esperam, e a errada sempre que dois leitores em fusos diferentes precisam concordar sobre um momento.
- Por que meu evento de dia inteiro aparece no dia errado?
- Porque foi escrito como um carimbo de data/hora à meia-noite em vez de como um valor de data. Um verdadeiro evento de dia inteiro usa VALUE=DATE sem nenhum horário, então não há nada para converter. Lembre-se também de que a data de término é exclusiva: um evento de um dia no dia 15 tem DTEND no dia 16.