Fuso do perfil, relógio da máquina e inconsistência que o checker não mostra

O checker devolve um score. Verde. O gestor lê timezone America/Sao_Paulo num cantinho da tela e segue. A conta de anúncio está em Brasília. O notebook, desde a última viagem, ficou em UTC. O JavaScript da página pergunta a hora. O sistema responde uma coisa. O perfil “spoofado” responde outra. O IP diz São Paulo. Nenhum widget único fecha essa conta. O verde era só o retrato de canvas. Fuso é outro eixo.

Inconsistência de horário é chata porque parece detalhe de relógio. Pra mesa, é o mesmo tipo de sinal barato que idioma e geo: ou a história é uma, ou é um conjunto de máscaras. Este texto não ensina a fabricar um fuso perfeito. Ensina a ler o que o teste de fingerprint não compara sozinho, e a escrever a política da agência remota sem mentir um país por login. O hub de comparativos lista stacks. O relógio é de vocês.

Três relógios, três depoimentos

Na prática existem três fontes. O time trata as três como se fossem uma.

Relógio da máquina. Windows, macOS. NTP ligado ou não. Fuso do SO que o gestor escolheu quando instalou o notebook, ou que a viagem alterou. Data errada quebra certificado. Fuso errado mente a hora local pra muita API.

Fuso do perfil de browser. O que o ambiente de isolamento declara via Intl, via Date, via offset. Pode herdar o SO. Pode estar fixado. Pode ter sido “ajustado pro proxy” numa sexta e esquecido.

Fuso da conta de anúncio. Google Ads, Meta, TikTok. Configuração de conta, de conjunto, de relatório. É o fuso em que a verba e o “hoje” existem. Não é JavaScript. É negócio.

Inconsistência é quando os três não contam a mesma história plausível. IP em São Paulo, conta em America/Sao_Paulo, SO em Tóquio, perfil em America/New_York. Ninguém precisa de um modelo interno da plataforma pra achar isso feio. É feio na mesa, no print, na reunião com o cliente que pergunta por que o conjunto “começou ontem”.

O checker típico mostra um timezone do JavaScript. Parabéns: você tem um valor. Falta cruzar com os outros dois. Cruzar é procedimento da mesa, não feature do site de teste.

O que o JavaScript realmente entrega

Páginas perguntam offset, nome de fuso, hora local. Intl.DateTimeFormat().resolvedOptions().timeZone é o nome longo. getTimezoneOffset() é o minuto. Eles podem divergir em caso patológico. Na agência, o caso patológico é configuração pela metade: offset spoofado, nome herdado, ou o contrário.

Horário de verão existe. O Brasil passou anos sem. Outros países não. Perfil fixo num offset de agosto quando a geo do IP está num país com DST vira um pixel de estranheza uma vez por ano. Não é o fim da conta. É mais um bit. Bits somam.

Relógio da máquina atrasado quinze minutos já foi suficiente pra cookie parecer expirado e gestor achar que “a sessão caiu, é ban”. Não era ban. Era NTP. Antes de fingerprint, a máquina precisa de hora certa. Isso é TI, não antidetect.

Não invente offset. Se a identidade é brasileira, o fuso da conta é Brasília, o proxy é São Paulo, o caminho honesto é America/Sao_Paulo no perfil e no SO da máquina de mídia — ou o aceite explícito de que o operador está em outro país, documentado, com horário de login coerente. O meio-termo — perfil em Nova York porque um tutorial disse que “fica mais limpo” — é teatro. Teatro é sinal.

Checker verde, conta torta

Como ler testes de fingerprint já insiste: score não é KPI de anúncio. Fuso ilustra o porquê. O laboratório mede unicidade de canvas, WebGL, áudio. Timezone entra como campo. Raramente o relatório diz “este campo briga com o IP que eu mesmo acabei de ver”. Raramente diz “este campo briga com o Ads Manager que você vai abrir depois”.

O fluxo errado: abrir checker, ver verde, logar BM, só então notar que os relatórios estão em Pacific Time porque alguém clonou campanha de um tutorial gringo. O fluxo certo: fuso da identidade escrito no inventário. Perfil e SO batem. Checker só confirma o que você já decidiu. Se o checker mostrar outro nome de fuso, o perfil está errado. Não a conta. Não o cliente.

Clonar perfil “que passou no teste” copia o fuso do perfil-fonte. Se a fonte era um lab em UTC e a produção é Brasília, você herdou o lab. Sandbox e produção não compartilham essa herança. Cada identidade tem a linha de fuso. Copiar ambiente não é copiar lugar.

Extensão de “spoof timezone” no Chrome vanilla é o atalho que o checker às vezes nem lê do mesmo jeito que a página de anúncio. Duas APIs, duas respostas. Isolamento de verdade declara um fuso no processo, não uma extensão que mente pra um site e esquece o outro.

Agência remota: gente em dois fusos

O caso honesto. Head em São Paulo. Gestor em Fortaleza — mesmo fuso. Gestor em Lisboa. Freelancer em Buenos Aires. A BM do cliente é Brasília.

Mentir que todo mundo está em Pinheiros, todo login, é pior do que admitir operação remota. O IP do residencial brasileiro com JavaScript de Lisboa toda terça, quando a pessoa realmente está em Lisboa, ainda é inconsistência. O IP local de Lisboa com conta brasileira é outro filme: geo, pagamento, termos. Não misture. O artigo de agência remota trata horário de login e sessão. Aqui o recorte é o relógio do perfil.

Política possível, escrita:

Máquinas de mídia da agência ficam em America/Sao_Paulo, mesmo o humano em outro país, se o contrato é operar a identidade brasileira naquele fuso — e o proxy/geo combinam. O humano aceita que o relógio da máquina não é o relógio da casa. Chato. Consistente.

Ou: o perfil herda o fuso real do operador, e o inventário registra operador-Lisboa, horário comercial sobreposto com Brasília, sem spoof. Também chato. Também honesto. O que não existe é spoof aleatório “pro checker gostar”.

Plantão. Quem pausa às 2h de Brasília precisa do perfil no fuso da conta. Se o plantão está em Manaus, o offset muda. O cartão de plantão inclui “não alterar fuso às 2h”. Alterar fuso é alterar lugar. Lugar não se altera no meio do incidente.

Relógio da máquina é higiene, não fingerprint

Notebook com bateria morta, relógio em 2018, certificado TLS recusado, gestor conclui que o proxy caiu. Outro notebook, horário de verão americano ligado por um clique errado em “ajuste automático”, offset -420 no meio de São Paulo.

Checklist de endpoint:

NTP ligado. Fuso do SO definido pela política da identidade, não pelo último aeroporto. Proibido o gestor “só mudar pra ver o horário local do hotel” no mesmo Windows que abre produção. Viagem: máquina de mídia não é o relógio de pulso. Ou leva um perfil de viagem documentado, ou não opera produção na rede do hotel.

BYOD. O Windows pessoal do gestor está em America/Fortaleza ou em UTC. A agência não controla. Por isso BYOD e conta de cliente brigam. Ou o perfil isola o fuso de verdade, ou a máquina entra no domínio da política. Meio-termo é o checker verde e o SO em Tóquio.

Atualização de sistema que “ajusta a hora”. Reteste amostral. Não diário. Não nunca.

Inventário: a coluna que o checker não cria

Identidade. Fuso da conta de anúncio. Fuso declarado do perfil. Fuso do SO da máquina padrão. Geo do proxy. Operador remoto (sim/não, cidade). Data do último print em que JavaScript e política bateram.

Quando o cliente muda o fuso da conta — acontece em migração, em conta criada por tutorial, em MCC herdada — a coluna da conta muda primeiro. Perfil e SO acompanham. Não o contrário. Não “vamos mudar o Ads pra combinar com o notebook do João”. João ajusta o notebook. A conta é do anunciante.

Campanhas com fuso próprio no Google. Conjuntos com horário de anúncio. Isso é mídia, não fingerprint. Não use horário de conjunto pra “corrigir” JavaScript. Use pra entregar o anúncio na hora do público. Os eixos se tocam na cabeça do gestor. No procedimento, separam.

O que não fazer

Não sortear timezone de país rico porque um fórum disse que reduz restrição. Isso é lenda. Mentir lugar não lava termos de uso.

Não alterar fuso com a sessão autenticada. Perfil vazio, ajuste, teste, login.

Não copiar fuso de um perfil de lab em UTC pra produção.

Não tratar offset -180 e America/Sao_Paulo como automaticamente iguais pra sempre. DST e nome importam. Use o nome da política.

Não explicar toda queda de entrega com “o fuso estava errado”. Entrega tem leilão, criativo, pixel, verba. Fuso é higiene de identidade. Higiene não substitui mídia.

Não pedir ao cliente que mude o fuso da BM “pra combinar com o antidetect”. O antidetect combina com a BM.

Horário de conjunto não conserta o JavaScript

Google Ads deixa fuso na conta e horário de anúncio no conjunto. Meta deixa programação. Isso é mídia: quando o anúncio entra no leilão. Não é o Date que a página de risco lê no login.

Gestor mistura os eixos. “A campanha está em horário de Brasília, então o perfil pode ficar em UTC.” Não. A campanha entrega em Brasília. O login ainda devolve o fuso do JavaScript. Os dois precisam ser coerentes com a identidade, mas um não substitui o outro.

Erro clássico: copiar uma campanha de um curso gringo, conjunto em Pacific Time, conta em Brasília, perfil em São Paulo. A entrega fica torta. O fingerprint fica torto se alguém “ajusta o perfil pra Pacific” pra combinar com o conjunto. Ajuste o conjunto. Deixe o perfil na identidade.

Outro erro: mudar o fuso da conta inteira pro notebook do freelancer em Lisboa “pra os relatórios baterem”. Os relatórios passam a mentir o dia do anunciante. O freelancer ajusta a cabeça. A conta fica.

Viagem, hotel e o relógio de pulso

O gestor pousa em Lisboa. O Mac pergunta se deve mudar o fuso. Ele clica sim. Na manhã seguinte abre produção. O JavaScript agora é Europa. O proxy ainda é São Paulo. A conta ainda é Brasília. Três depoimentos.

Máquina de mídia não é relógio de pulso. Ou a política trava o fuso do SO, ou a pessoa não opera produção na viagem. Perfil de viagem, se existir, é outra identidade no inventário, testada, com geo coerente — o que quase nunca é o caso de uma terça em hotel.

Não mude o fuso às 2h “só pra ver o horário local” e esqueça de voltar. O esquecimento vira o depoimento da quarta-feira. Alarme ruim. Procedimento melhor: o SO da máquina de ads não pergunta. TI trava. BYOD não trava. Por isso BYOD e produção brigam.

Ritual curto, perfil vazio

Antes do primeiro login da identidade, e depois de viagem, home office novo, clone de perfil:

Confira o fuso da conta no painel, logado no perfil já consistente — ou no papel de ver, se ainda não autenticou neste ambiente. Se ainda não autenticou: o fuso da conta já deveria estar no inventário, copiado na sexta pelo sênior.

Confira o SO. Confira o JavaScript no mesmo checker de sempre. Os nomes batem com a política. Print.

Só então Ads Manager.

Se não bater, não “vai assim que o score está alto”. Score alto com fuso de Nova York em conta de Brasília é o retrato de um laboratório, não de um anunciante. O checker não ia mostrar a briga. Você mostra. Essa é a parte chata que importa.