Resumo

  • O RFC 867 definiu a porta, o transporte e o encerramento do Daytime, mas declarou que a data não possuía sintaxe específica; seus dois exemplos eram só formatos populares.
  • Para tempo útil a máquinas, o próprio texto indicava o Time Protocol, cuja quantidade fixa de 32 bits fazia outro tipo de promessa.
  • A história mostra que legibilidade e interoperabilidade semântica são decisões separadas: caracteres válidos não autorizam uma interpretação única do instante.

Duas respostas válidas e nenhuma regra comum

Uma máquina responde Monday, February 22, 1982 17:37:43-PST; outra prefere 02 FEB 82 07:59:01 PST. Uma pessoa identifica duas datas. Um programa precisa decidir onde fica o ano, quantos dígitos ele tem, como o fuso é separado, se o dia da semana deve aparecer e qual campo vence caso os dois discordem.

O RFC 867 não tornou nenhum exemplo obrigatório. Primeiro afirmou que não existia sintaxe específica para o Daytime; depois apresentou duas formas populares. Um analisador capaz de ler uma delas implementa uma convenção local, não um formato universal concedido pelo RFC.

Assim, a rede pode funcionar enquanto a transformação semântica continua indefinida. A conexão abre, os bytes chegam e o servidor fecha. Isso prova a execução do serviço, não que clientes independentes possam reconstruir o mesmo instante.

Um contrato pequeno e preciso

Publicado em maio de 1983, o RFC 867 descreveu o Daytime como ferramenta de depuração e medição. Em TCP, o servidor ouvia a porta 13, enviava a data e a hora atuais em uma cadeia ASCII, descartava dados recebidos e fechava a conexão. Em UDP, qualquer datagrama recebido na porta 13 provocava uma resposta com data e hora; o conteúdo da consulta era ignorado.

O documento recomendava caracteres ASCII imprimíveis, espaço, retorno de carro e mudança de linha, com uma única linha de resposta. Era suficiente para inspeção direta com ferramentas simples e para reconhecer o fim da resposta.

Não havia ordem de campos, pontuação, precisão, ano de quatro dígitos, relação com UTC, segundo intercalar, idioma, qualidade do relógio ou prova de origem. “Atual” era a afirmação do servidor sobre seu relógio, não um certificado de sincronização. ASCII limitava os bytes, não a ambiguidade do calendário.

A porta registrada tampouco completava o significado. Ela dava um nome comum ao serviço esperado, mas não fazia do operador uma autoridade temporal nem tornava uma sigla alfabética de fuso inequívoca.

Para cálculo, havia outra porta

A nota final do RFC 867 orientava usar o RFC 868 para tempo útil a máquinas. O Time Protocol devolvia na porta 37 um inteiro sem sinal de 32 bits: os segundos desde o início de 1900. Daytime oferecia uma linha legível na 13; Time oferecia uma quantidade fixa na 37.

Por isso, Daytime não deve ser tratado como tentativa fracassada de serialização. Sua função humana era deliberada. Um técnico podia verificar a resposta e olhar o relógio sem decodificador. Um aplicativo que precisasse calcular deveria escolher o contrato numérico vizinho.

O catálogo RFC 880, de outubro de 1983, classificou Daytime como elective — o host podia implementar ou não — e Time como recommended. Essa condição histórica não revela uso atual, mas registra a diferença de prioridade entre um diagnóstico legível e um valor comum para software.

O número fixo também tinha limites: não exibia fuso ou calendário e enfrentaria questões de era. Este artigo não repete a história de 2036 e NTP; usa o RFC 868 apenas no papel de contraste apontado pelo próprio Daytime.

O exemplo que errou o dia da semana

O primeiro exemplo do RFC 867 originalmente chamou 22 de fevereiro de 1982 de terça-feira. Era segunda-feira. O RFC Editor verificou em 2025 o erratum 8551 e corrigiu a palavra. Trata-se de ajuste editorial, não revisão do protocolo nem evidência sobre servidores reais.

Mesmo assim, o erro demonstra algo específico: dia da semana e data completa carregam informação redundante e podem contradizer-se. A pessoa percebe a tensão; o programa precisa de uma regra de precedência. O Daytime não fornecia essa regra porque não fornecia uma gramática.

Anos depois, o RFC 3339 descreveu o mesmo risco ao definir marcas de tempo para protocolos. Excluiu o dia da semana, exigiu anos de quatro dígitos e uma relação declarada com UTC, usando deslocamento numérico ou Z em vez de depender de siglas de fuso com interoperabilidade ruim.

Não há sucessão normativa: o RFC 3339 não substituiu o RFC 867, e o erratum de 2025 não causou um texto de 2002. A comparação serve para localizar a decisão. No Daytime, o servidor escolhe a apresentação. No RFC 3339, a representação de rede fica estável e cada cliente escolhe como exibi-la.

Quando texto humano vira API oculta

Protocolos legíveis barateiam a depuração, como reconhece o próprio RFC 3339. Mas uma data natural em um país pode ser ambígua em outro. Intercâmbio global exige separar formato de fio e formato de tela.

Enquanto uma pessoa olha a linha do Daytime, a liberdade de apresentação é útil. Quando um script captura a saída, ajusta uma expressão regular a um servidor e guarda apenas o valor convertido, pontuação e vocabulário viram uma API sem contrato.

O operador pode alterar o formato e continuar totalmente conforme ao RFC 867, enquanto o consumidor quebra. Isso não é infração do servidor; é o resultado de elevar uma observação local a garantia que o padrão nunca deu.

Automação responsável preserva a linha como evidência opaca ou firma uma convenção separada e explícita para sintaxe, fuso e erros. Analisar com sucesso ontem não cria autoridade normativa para amanhã.

Registro IANA não é ordem de exposição

A IANA ainda registra daytime em TCP e UDP na porta 13 e referencia o RFC 867. Isso preserva o significado do nome. Não prova implantação, segurança, precisão ou obrigação de manter o serviço público.

A variante UDP pede uma decisão operacional moderna. Ela responde sem interpretar o pedido, e o endereço IP de origem pode ser falsificado. O RFC 8085 alerta, de forma geral, que pedidos curtos e não autenticados capazes de gerar respostas maiores podem servir à amplificação, recomendando limitar respostas ou autenticar remetentes conforme o cenário. As fontes não medem abuso atual do Daytime nem um fator universal.

O operador deve justificar por que o serviço é alcançável. Estabelecer TCP não autentica o relógio; a origem UDP não autentica o solicitante; texto claro não autentica a hora.

O valor de saber onde a norma parou

O RFC 867 tornou previsíveis a abertura, a resposta e o encerramento, conservou a saída legível e recusou a promessa de sintaxe de máquina. Essa contenção era parte do desenho.

É possível programar um analisador para qualquer resposta observada. A pergunta decisiva é se a norma autoriza esperar que ele funcione com todos os servidores conformes e suas mudanças futuras. Para Daytime, não autoriza.

Interoperabilidade tem camadas. A porta pode ser comum quando a gramática não é. Os caracteres podem ser válidos quando o instante é ambíguo. O servidor pode cumprir o padrão enquanto a automação falha. Ler um protocolo exige conhecer tanto suas garantias quanto as inferências que ele deliberadamente deixou de fora.

Fontes e limites

O comportamento está no RFC 867, com a correção no registro de errata. O contraste de máquina vem do RFC 868 e a classificação histórica do RFC 880.

O RFC 3339 fornece a comparação posterior; o RFC 6335 e o registro IANA delimitam o nome da porta; o RFC 8085 delimita UDP moderno. As fontes não medem implantação, exatidão ou ataques atuais.