A exportação JSON guarda três coisas para as quais o CSV não tem coluna

Um retângulo contra uma forma

Um CSV tem de fixar as suas colunas antes de escrever a primeira linha, e todas as seguintes têm exatamente essas. É uma força quando queres ordenar por data de início ou contar eventos por local — uma folha de cálculo faz isso num instante e um ninho de objetos não. Torna-se fraqueza assim que os dados são irregulares, e os dados de calendário são-no por natureza: quase nenhum evento tem recorrência, alguns têm; quase todos têm fuso, os de dia inteiro não.

Há uma segunda diferença, mais discreta, a conhecer quando um script lê a saída. No CSV um campo vazio é uma célula vazia sempre presente; no JSON um campo opcional sem valor pode faltar por completo no objeto. Escreve o teu leitor de modo que uma chave ausente e uma cadeia vazia sejam tratadas igual e nenhuma das exportações te surpreenderá.

Perguntas frequentes

Posso voltar a transformar o JSON em calendário?

Não diretamente aqui — o lado da importação recebe CSV — mas o JSON é o que convém dar a um script que escreva .ics por si, precisamente porque guarda ainda o fuso, o indicador de dia inteiro e a regra. Se só queres mover um calendário sem o alterar, não passes por nenhuma das exportações: juntar ficheiros .ics guarda tudo e evita a questão.

O JSON desdobra os eventos recorrentes?

Não, e não deveria: leva a regra em vez disso, o que é estritamente mais informação. Um objeto com um rrule de FREQ=WEEKLY;COUNT=12 diz-te ao mesmo tempo que há doze ocorrências e como se espaçam, ao passo que doze objetos desdobrados te dariam as datas perdendo o facto de andarem juntas. Desdobrar é trabalho de quem consome o ficheiro.

Qual devo arquivar?

O próprio .ics. Ambas as exportações são leituras dele, e uma leitura deixa sempre algo de fora — o JSON deixa participantes, alarmes e anexos, tal como o CSV deixa o fuso e a regra. Guarda o original como referência e gera a exportação de que precisares quando precisares.