Envios internacionais de SMS A2P: como programar pela hora local sem erros de fuso horário

Por que a hora deve ser avaliada no fuso horário do destinatário

Uma hora de envio expressa apenas em UTC ou no fuso horário da equipa que opera a campanha não garante que a mensagem chegue dentro do horário previsto para cada destinatário. Para uma programação local, é necessário agrupar os contactos segundo um fuso horário fiável e converter a hora pretendida no instante correspondente.

Convém distinguir três conceitos: a hora local pretendida, o instante calculado para o envio e a hora em que o sistema entrega a mensagem à rota ou à plataforma de saída. Uma campanha programada não garante a receção no telemóvel a uma hora exata: o processamento, a conectividade e a rede podem influenciar o momento efetivo.

• Defina se a campanha pretende respeitar uma hora local comum a todos ou uma única hora de referência para toda a operação.
• Guarde internamente o instante calculado num formato inequívoco, como UTC, além da hora local apresentada ao operador.
• Não apresente a hora programada como garantia de entrega ao dispositivo.

Que dados são necessários para atribuir um fuso horário

A conversão é tão fiável quanto o fuso horário atribuído ao destinatário. O indicativo telefónico não deve ser tratado como identificação suficiente do fuso horário: a numeração e a localização temporal não são equivalentes, e as fontes disponíveis não comprovam um método para inferir um fuso horário fiável apenas a partir do número.

Quando for pertinente e permitido, utilize um dado de fuso horário fornecido pelo utilizador ou uma localização com precisão suficiente e fundamento válido. Registe também a origem do dado e quando foi obtido. Se o fuso horário for inferido, identifique-o como tal e defina o nível de incerteza aceite pela política.

Se apenas conhecer o país, não presuma que existe um único fuso horário nacional. Os países podem abranger vários fusos, e há também territórios com regras próprias. Se não houver uma localização temporal suficientemente fiável, aplique uma regra de contingência explícita, como reter a mensagem para revisão ou utilizar uma janela conservadora previamente validada.

• Defina uma hierarquia de fontes para atribuir fusos horários: dado explícito, localização fiável permitida, inferência documentada e, por último, dado desconhecido.
• Não deduza a hora local a partir do indicativo telefónico sem uma fonte e um método validados para esse fim.
• Estabeleça o que fazer com números cujo fuso horário não possa ser determinado; não os atribua silenciosamente ao fuso horário do remetente.

Países com vários fusos horários, territórios e localização desconhecida

A política deve operar com fusos horários concretos, e não apenas com designações de países. Para cada destinatário, a aplicação precisa de um fuso horário de referência definido e de uma regra para contactos cujos dados sejam ambíguos ou insuficientes.

Antes de ativar uma campanha multinacional, verifique como os territórios e os vários fusos horários são tratados nos seus dados e no sistema de programação. Se a plataforma permitir apenas um fuso horário predefinido, documente o âmbito dessa configuração e avalie se é adequada a cada segmento. Um fuso horário predefinido pode servir como recurso operacional, mas não transforma um dado desconhecido numa atribuição fiável.

• Mantenha uma correspondência passível de revisão entre os segmentos de destinatários e os fusos horários concretos.
• Separe os casos confirmados dos inferidos e dos desconhecidos para aplicar controlos distintos.
• Não inicie o envio para um segmento ambíguo antes de decidir como resolver a ambiguidade e quem autoriza essa decisão.

Hora de verão: horas inexistentes, repetidas e regras em mudança

Nos locais onde o relógio muda, uma hora local pode não existir durante o avanço sazonal ou pode repetir-se durante o atraso. Uma programação que aceite apenas uma data e hora local pode ser ambígua nesses momentos. As regras também podem mudar, pelo que uma conversão calculada com dados temporais desatualizados pode deixar de corresponder à hora local pretendida.

Não existe uma resolução universal que se possa considerar válida para todos os destinos. A política deve especificar o que fazer com uma hora inexistente — por exemplo, rejeitá-la ou ajustá-la segundo uma regra aprovada — e como distinguir as duas ocorrências de uma hora repetida. A opção concreta deve ser coerente com a finalidade da mensagem e com os controlos legais aplicáveis.

Utilize um mecanismo de fusos horários atualizado e registe a versão ou a referência das regras utilizadas, quando o sistema o permitir. Se não conseguir verificar como uma plataforma gere as transições, teste esse comportamento antes de a utilizar em produção.

• Defina o tratamento das horas inexistentes e repetidas; não deixe a decisão implícita no comportamento do sistema.
• Reveja as programações futuras se as regras aplicáveis a um fuso horário mudarem.
• Distinga a hora local pedida da conversão calculada e guarde ambas para poder explicar o resultado.

Defina uma política de programação antes de carregar a campanha

Uma política útil estabelece como o fuso horário é obtido, que hora se pretende respeitar e o que acontece quando faltam dados. Também deve distinguir a viabilidade técnica da autorização para enviar: uma conversão correta não demonstra que a mensagem é permitida nessa jurisdição nem que existe consentimento válido.

Não existe uma única janela internacional que possa ser aplicada sem revisão. Verifique os horários permitidos, as restrições de mensagens, os feriados e outras obrigações com as fontes oficiais pertinentes para cada jurisdição e tipo de mensagem. Se não tiver confirmado uma regra local, não a transforme numa suposta norma global nem presuma que a ausência de regras equivale a autorização.

• Defina a hora local pretendida e as janelas operacionais de cada segmento.
• Estabeleça uma regra de contingência para fusos horários desconhecidos e um processo de aprovação de exceções.
• Valide separadamente o consentimento, a finalidade, as restrições legais e a programação técnica.
• Consulte fontes oficiais para rever as regras locais antes de ativar ou alterar uma campanha.

Filas, atrasos e reagendamento

A hora de execução calculada pode ficar no passado se uma fila sofrer atrasos ou ocorrer uma interrupção. O sistema deve ter uma regra explícita para esse caso: descartar a mensagem, solicitar aprovação, enviá-la dentro de uma janela ainda válida ou calcular uma nova hora local. A escolha depende da finalidade, da atualidade do conteúdo e das regras aplicáveis; não deve ser um reenvio automático sem limites.

Para campanhas de longa duração, considere que uma atualização das regras de fuso horário pode afetar mensagens ainda pendentes. Defina quem revê essas alterações e como as tarefas afetadas são recalculadas. Se a hora for alterada, guarde a programação original e a nova para não perder o contexto operacional.

• Especifique o que fazer se o envio se atrasar para além da janela autorizada.
• Evite que reenvios ou reagendamentos transformem uma mensagem oportuna numa mensagem desatualizada ou fora da janela.
• Aplique controlos e limites de novas tentativas adequados à plataforma e à política interna, sem presumir garantias de entrega.

Rastreabilidade de cada decisão temporal

Um registo útil permite reconstruir por que motivo uma mensagem foi programada para determinado instante. Conserve, de acordo com as necessidades de privacidade e retenção da sua organização, a hora local pretendida, o fuso horário atribuído, a origem ou o nível de confiança dessa atribuição, o instante calculado e a versão das regras temporais utilizadas.

Acrescente a hora de execução efetiva registada pelo sistema e o resultado de envio disponível. Interprete com prudência os estados de entrega: um DLR recebido é um estado reportado por uma rota ou sistema, não uma verificação independente de que o destinatário leu a mensagem, nem uma garantia de receção no dispositivo.

• Registe a hora pretendida e a hora calculada em campos distintos.
• Guarde alterações, exceções e decisões manuais, com a data e o responsável operacional.
• Limite os dados pessoais e o período de conservação ao que for justificado pelas suas necessidades e obrigações.

Matriz de testes antes da entrada em produção

Teste a lógica de conversão por fuso horário, e não apenas uma campanha numa data corrente. Inclua casos com vários fusos horários no mesmo país, territórios relevantes, fuso horário desconhecido, uma data de mudança sazonal e alterações numa programação pendente. Os testes devem verificar tanto o resultado como a decisão aplicada quando a hora é ambígua.

A lista seguinte é uma base operacional, não uma especificação universal. Complete os casos com os fusos horários, as regras legais e os comportamentos reais da plataforma que utiliza. Se o sistema não permitir verificar ou controlar um caso crítico, documente essa limitação e adote uma alternativa segura antes do envio.

• Compare a hora local pretendida com o instante UTC calculado em vários fusos horários.
• Teste uma hora inexistente e uma hora repetida, confirmando que a política definida é aplicada.
• Verifique o tratamento dos destinatários sem localização temporal fiável.
• Simule atrasos na fila dentro e fora da janela prevista.
• Verifique o efeito da alteração de uma programação pendente após uma atualização das regras temporais.
• Confirme que os registos permitem reconstruir a decisão e distinguir o envio registado da receção final.