Horas puladas, horas repetidas e como agendadores de redes sociais lidam com fusos horários

Como agendadores de redes sociais lidam com fusos horários?

Por baixo dos panos, a forma como agendadores de redes sociais lidam com fusos horários se resume a uma regra: guardar o horário de relógio que a pessoa escolheu junto com o nome de zona IANA em que ela o escolheu, e transformar esse par em um instante UTC só quando uma API de plataforma precisa de um timestamp. "9:00 em America/New_York em 15 de julho" é a intenção. 2026-07-15T13:00:00Z é o que a API recebe.

O nome da zona importa porque carrega as regras. O IANA Time Zone Database, que a IANA descreve como contendo "the history of local time for many representative locations worldwide", é "updated periodically to reflect changes made by political bodies to time zone boundaries, UTC offsets, and daylight-saving rules." A versão listada em iana.org quando esta página foi escrita era a 2026d. Um nome como Europe/Berlin aponta para essas regras. Um offset como +01:00 não aponta para nada e fica desatualizado duas vezes por ano.

Todas as outras decisões de design vêm dessa separação entre intenção e instante. O resto desta página mostra onde cada metade quebra.

Por que um offset UTC fixo é a coisa errada a guardar?

Um offset fixo registra o que o relógio marcava em um dia e supõe que isso vale para sempre. Guarde 9:00 no horário de Nova York em janeiro como 09:00-05:00, reutilize esse offset para um post de julho, e o post sai em 2026-07-15T10:00:00-04:00. Isso é 10:00 no horário local, uma hora atrasado, porque Nova York fica em UTC-4 no verão.

A RFC 9557, o documento do IETF que acrescenta nomes de zona entre colchetes aos timestamps da RFC 3339, alerta exatamente contra isso. Ela chama offset time zones de "strongly discouraged" e diz que programas "MUST NOT copy the UTC offset from a timestamp into an offset time zone." O próprio exemplo dela mostra o porquê: 2020-01-01T00:00+01:00[Europe/Paris] permite a um programa somar seis meses e cair no horário de verão correto, enquanto o mesmo cálculo sobre 2020-01-01T00:00+01:00[+01:00] "will produce an incorrect result that will be off by one hour in the time zone Europe/Paris."

O mesmo bug se esconde em posts recorrentes. Um horário semanal salvo como "toda segunda às 08:00 UTC" escorrega uma hora para todo mundo fora do UTC quando os relógios mudam. Um horário salvo como "toda segunda às 08:00 Europe/London" não escorrega.

O que acontece com um post agendado na hora pulada?

Ele aponta para um horário que nunca existe, e o agendador precisa escolher um real. Em 2026, Nova York adianta os relógios de 02:00 para 03:00 em 8 de março, às 07:00Z. Nada entre 02:00 e 02:59 acontece nessa data. Um post marcado para 02:30 não tem instante correspondente.

A API Temporal do JavaScript torna a escolha explícita pela opção disambiguation, que aceita "compatible", "earlier", "later" ou "reject". O MDN documenta o padrão assim: "compatible (default): Same behavior as Date: use later for gaps and earlier for ambiguities." Com "compatible", 02:30 vira 03:30 EDT, que é 07:30Z. O zoneinfo do Python dá o mesmo instante para fold=0 e 06:30Z, uma hora antes, para fold=1.

"reject" é a escolha honesta para uma interface de agendamento. Recuse o horário e diga à pessoa que 02:30 não existe naquela noite, em vez de mover o post dela sem avisar. Para um job em segundo plano que precisa disparar de qualquer jeito, "compatible" é a regra menos surpreendente, e ela corresponde ao que o Date já faz.

O que acontece na hora repetida?

O mesmo horário de relógio acontece duas vezes, e o agendador precisa escolher um. Em 1º de novembro de 2026, Nova York volta de 02:00 EDT para 01:00 EST às 06:00Z, então 01:30 ocorre uma vez às 05:30Z e de novo às 06:30Z. Os timestamps UNIX são 1793511000 e 1793514600, exatamente 3.600 segundos de diferença.

A regra do MDN para "compatible" é "earlier for ambiguities", então um agendador baseado em Temporal posta no primeiro 01:30. O zoneinfo do Python faz o mesmo para fold=0. De um jeito ou de outro, a regra precisa estar no código, porque nada em "01:30 America/New_York" diz qual dos dois instantes a pessoa quis dizer. Um calendário que mostra as duas opções nessa única noite evita o palpite.

Por que a diferença entre EUA e Europa importa para postagens globais?

As duas regiões mudam os relógios em datas diferentes, então a diferença entre elas não é constante. Em 2026, Londres e Berlim adiantam os relógios em 29 de março às 01:00Z, três semanas depois de Nova York. De 8 a 29 de março, Nova York fica quatro horas atrás de Londres em vez de cinco. No outono, a Europa atrasa os relógios em 25 de outubro e Nova York em 1º de novembro, o que abre mais uma semana com quatro horas.

Essas datas vêm do tz database, não de uma regra de bolso. Um agendador que fixa no código "Londres é Nova York mais cinco" posta com uma hora de erro durante quatro semanas por ano. Um que converte cada post pelo seu próprio nome de zona acerta as quatro semanas sem casos especiais. Isso pesa mais quando uma campanha sai para várias regiões, cada uma no seu melhor horário para postar nas redes sociais.

Quais formatos de horário as APIs das plataformas aceitam?

Toda API de plataforma que aceita um horário futuro quer um instante absoluto: um inteiro UNIX ou uma string ISO 8601 ou RFC 3339 com offset ou Z. Nenhuma delas aceita um nome de zona IANA. A tabela cobre os campos de agendamento que a própria documentação de cada plataforma descreve.

Dois detalhes dessa tabela pegam as pessoas de surpresa. O guia da Pages API da Meta escreve o padrão como "ISO 8061", erro de digitação de ISO 8601 na página que define o campo. E os Reels do Facebook aceitam só a forma inteira, então um agendador que envia strings ISO para /feed precisa de um caminho de código separado para Reels.

O Bluesky é um caso especial. Ele não tem campo de agendamento, mas todo registro de post carrega um createdAt obrigatório, que o lexicon descreve como "Client-declared timestamp". A especificação do atproto diz "Timezone specification is required" e "It is strongly preferred to use the UTC timezone, and to represent the timezone with a simple capital Z suffix." Um post do Bluesky na fila deve receber o createdAt no momento do envio, não no momento em que foi rascunhado.

Alguma API de plataforma aceita um nome de fuso horário?

Não. Nenhuma das documentações de agendamento de plataformas tratadas aqui aceita uma string como America/New_York. A conversão de nome de zona para instante é sempre trabalho do agendador, e a plataforma nunca vê a zona.

O Facebook é quem chega mais perto de fazer a conversão por conta própria, e essa é a parte arriscada. O guia da Meta aceita strings relativas de strtotime() como +2 weeks e tomorrow, mas não diz em qual zona "tomorrow" é resolvido. O próprio conselho da Meta é que "If you are relying on strtotime()'s relative date strings you can read-after-write the scheduled_publish_time of the created post to make sure it is what is expected." Um agendador que envia um timestamp UNIX já calculado nunca precisa dessa conferência.

A RFC 9557 define, sim, um lugar para um nome de zona, como sufixo entre colchetes: 2022-07-08T00:14:07+01:00[Europe/Paris]. Nenhum dos endpoints de agendamento acima documenta suporte a esse sufixo, então remova-o antes de enviar. O detalhe por plataforma de dois desses campos está nas regras de antecedência do scheduled_at do Mastodon e em cada campo publishAt do YouTube e seus modos de falha.

O que um agendador deve guardar para cada post?

Três coisas: o horário de relógio local, o nome de zona IANA e o instante UTC derivado dos dois. Os dois primeiros são a fonte da verdade. O terceiro é um cache para a fila ordenar e disparar.

O motivo para guardar o horário local é que as regras de zona mudam depois que você agenda. O MDN diz isso sem rodeios: "if you store a time in the future, with an anticipated offset, then before that time comes, the time zone definition may have changed due to political reasons." Quando sai uma atualização do tz database, recalcule o instante UTC de cada post futuro a partir do horário de relógio e da zona. Um sistema que guardou só o UTC não consegue fazer isso, porque não sabe mais o que a pessoa pediu.

A outra metade é o caminho de envio. Converta para o formato que cada API quer no momento do disparo: um inteiro para os Reels do Facebook, ISO com sufixo Z para YouTube e Mastodon, minutos inteiros para o X Ads. Confira o resultado contra a antecedência mínima da plataforma antes de enviar. O Mastodon rejeita qualquer coisa a menos de 5 minutos, e o Facebook rejeita qualquer coisa a menos de 10. Acertar essas conferências é boa parte do que separa uma fila confiável de uma que agenda posts nas redes sociais na hora errada duas vezes por ano.

Perguntas frequentes

Um agendador de redes sociais deve guardar os horários em UTC?

Guarde o instante UTC para ordenar e disparar, mas não como único registro. Guarde também o horário de relógio e o nome de zona IANA, para que o instante possa ser recalculado quando o tz database mudar as regras de uma zona. O MDN observa que a definição de uma zona "may have changed due to political reasons" antes de um horário futuro chegar.

O que é um nome de fuso horário IANA?

É um identificador do IANA Time Zone Database, como America/New_York, Europe/London ou Asia/Tokyo. Cada nome aponta para o histórico completo de offsets UTC e regras de horário de verão daquele local. A IANA descreve o banco de dados como "updated periodically to reflect changes made by political bodies".

O que acontece se eu agendar um post para 2:30 da manhã na noite em que os relógios são adiantados?

Em Nova York, em 8 de março de 2026, 02:30 não existe. Pela regra padrão "compatible" do Temporal, o post avança para 03:30 EDT, 07:30Z. Com "reject", o agendador lança um RangeError, o que permite à interface pedir que a pessoa escolha outro horário.

O scheduled_publish_time do Facebook aceita um fuso horário?

Só como offset dentro de uma string ISO 8601, como 2018-09-01T10:15:30+01:00, que é o próprio exemplo da Meta. Ele também aceita um timestamp UNIX em segundos e strings de strtotime(). O guia da Meta não diz em qual zona strings relativas como tomorrow são resolvidas, e recomenda ler o valor de volta para conferir.

Qual formato a API do YouTube quer para o publishAt?

O recurso videos do Google diz que status.publishAt "is specified in ISO 8601 format." Envie data e hora completas com Z ou um offset explícito. O Google documenta que um valor no passado publica o vídeo "right away", então um bug de conversão que joga o horário para o passado faz o vídeo entrar no ar na hora em vez de devolver um erro.

Por que meus posts agendados ficam uma hora fora depois que o horário de verão acaba?

A causa mais comum é um offset fixo guardado. Um post salvo como 09:00-04:00 no verão continua disparando às 13:00 UTC depois que os relógios mudam, o que dá 08:00 em Nova York no inverno. Guardar America/New_York com o horário de relógio e recalcular o instante resolve.

O que acontece com um post agendado para 1:30 quando os relógios são atrasados?

Em 1 de novembro de 2026, Nova York repete de 01:00 a 01:59, então 01:30 acontece às 05:30Z e de novo às 06:30Z. Com a regra padrão "compatible" do Temporal, e com o zoneinfo do Python com fold=0, o post sai na primeira. A regra precisa estar no código do agendador, porque "01:30 America/New_York" não diz qual dos dois instantes a pessoa quis.

Por que Nova York fica só quatro horas atrás de Londres em algumas semanas?

Os EUA e a Europa mudam os relógios em datas diferentes. Em 2026, Nova York adianta o relógio em 8 de março e Londres em 29 de março, e entre as duas datas Nova York fica quatro horas atrás de Londres em vez de cinco. No outono abre-se outra semana de quatro horas, de 25 de outubro, quando a Europa atrasa o relógio, até 1 de novembro, quando Nova York faz o mesmo.

Dá para agendar um post pela API do Instagram ou do LinkedIn?

Nas documentações cobertas por este artigo, os endpoints de criação de Instagram, Threads, LinkedIn, TikTok, Pinterest e X API v2 não têm campo de hora futura. Facebook, YouTube, Mastodon e X Ads têm. Para o primeiro grupo, o agendador precisa guardar o post e enviá-lo quando a hora chegar.

Que timestamp um post do Bluesky deve ter?

O Bluesky não tem campo de agendamento, mas todo registro de post exige um createdAt, que o lexicon descreve como "Client-declared timestamp". A especificação do atproto exige indicar o fuso e prefere fortemente UTC com um Z maiúsculo como sufixo. Um post na fila deve receber o createdAt no envio, não quando foi rascunhado.