O mesmo ficheiro .ics pode designar cinco horas diferentes

Porque é que o ficheiro nomeia um fuso em vez de um desvio

Escrever +02:00 fixaria a reunião a um número que deixa de ser verdadeiro duas vezes por ano. Um compromisso semanal às 14:00 em Paris é +02:00 em setembro e +01:00 em novembro, e a graça de um evento recorrente é que fica às duas da tarde dos dois lados da mudança. Nomear Europe/Paris diz que regulamento aplicar; o desvio consulta-se depois, data a data, numa base de fusos atualizada sempre que um país mexe nos relógios.

É também por isso que converter uma hora TZID para UTC não é uma subtração que se faça de cabeça, e por isso uma ferramenta sem base de fusos não o deve tentar. Guardar o nome e os algarismos de relógio exatamente como o ficheiro os escreveu não perde nada; substituí-los por um instante calculado a partir do fuso errado perde, e é o tipo de erro que parece normal no ecrã até alguém entrar numa videochamada uma hora atrasado.

O evento de dia inteiro, que não é uma hora

Um aniversário, um feriado ou um dia de folga escreve-se DTSTART;VALUE=DATE:20261225 — oito algarismos, sem hora, e o parâmetro que o diz. Significa todo o 25 de dezembro onde quer que o leitor esteja, o que é exatamente certo para o Natal e seria falso como instante. Reescreve-o como data-hora e torna-se meia-noite UTC, que ainda é dia 25 na Europa e já é 24 a oeste de Greenwich. O marcador VALUE=DATE é transmitido aqui tal e qual, em vez de resolvido numa hora.

O que verificar antes de confiar num calendário importado

Abre o ficheiro no visualizador e olha para um evento de que conheças a hora real. Se estiver certa aí, o ficheiro está certo, e qualquer desacordo posterior vem da aplicação para onde importaste. Três hábitos cobrem quase tudo: prefere a forma Z quando publicares um calendário a que outros se subscrevam, guarda o TZID quando moveres o teu próprio calendário entre aplicações, e nunca edites uma hora de início à mão num editor de texto sem ver em qual das três formas a linha está escrita.

Perguntas frequentes

Os meus eventos importados estão todos desfasados uma ou duas horas. O que aconteceu?

Um desvio constante em todos os eventos é a assinatura de um fuso retirado e substituído. Abre o .ics original no visualizador: se as horas de início parecerem certas aí, o ficheiro guardou o seu fuso e é a aplicação de importação que aplica outro — verifica a sua definição de fuso do calendário, distinta da do sistema. Um desvio que varia de evento para evento é outro problema, normalmente uma mistura de horas Z e flutuantes no mesmo ficheiro.

Que forma devo usar quando publico um calendário?

Z para tudo o que tenha um instante fixo — um webinar, um jogo, um prazo — porque nada o pode ler mal e não é precisa base de fusos do outro lado. TZID para um calendário que as pessoas vivem localmente, como um horário escolar ou o de um escritório, onde é a hora de relógio que tem de ficar no lugar na mudança de hora. VALUE=DATE para dias inteiros. Horas flutuantes só quando queres mesmo dizer hora local em todo o lado, o que na prática se resume ao Ano Novo e a pouco mais.

O visualizador modifica o meu ficheiro?

Não. Lê o ficheiro no teu navegador e mostra o que ele contém; o ficheiro em disco não é tocado, e nada é enviado para lado nenhum. É esse o sentido de olhar antes de converter: podes resolver uma discussão sobre uma hora de início sem te comprometeres com nada.