Resumen

  • RFC 867 determinó el puerto, el transporte y el cierre de Daytime, pero declaró expresamente que la fecha no tenía una sintaxis específica.
  • Sus dos formatos de ejemplo eran costumbres populares, no un contrato de análisis. Para el tiempo útil a una máquina, el propio RFC remitía al protocolo Time.
  • La historia distingue legibilidad de interoperabilidad semántica: recibir caracteres válidos no concede autoridad para convertirlos de una única manera en un instante.

Dos respuestas conformes que exigen dos decisiones

Una pantalla muestra Monday, February 22, 1982 17:37:43-PST; otra devuelve 02 FEB 82 07:59:01 PST. Cualquier lector entiende que ambas líneas hablan de fecha y hora. Un programa, en cambio, debe decidir dónde está el año, cuántos dígitos tiene, cómo representa la zona, si el día de la semana es obligatorio y qué hacer cuando contradice la fecha.

RFC 867 no eligió uno de esos formatos. Los llamó ejemplos populares después de afirmar que Daytime carecía de sintaxis específica. Por eso un analizador que acepte una de las líneas implementa una convención observada, no una gramática universal otorgada por el estándar.

El intercambio puede ser correcto en su capa de transporte y seguir abierto en su significado computable. El servidor prometió una línea que una persona pudiera leer. No prometió que clientes independientes produjeran el mismo valor temporal a partir de ella.

La precisión estaba en la mecánica, no en la fecha

RFC 867 apareció en mayo de 1983 y describió Daytime como una herramienta de depuración y medición. En TCP, el servidor escuchaba el puerto 13, enviaba la fecha y hora actuales como texto ASCII, descartaba cualquier dato recibido y cerraba la conexión. En UDP, cualquier datagrama al puerto 13 provocaba un datagrama de respuesta cuyo contenido era la fecha y hora; la carga de la consulta se ignoraba.

El documento recomendaba caracteres ASCII imprimibles, espacio, retorno de carro y salto de línea. También recomendaba una sola línea. Había, por tanto, un contrato suficiente para abrir, recibir y mostrar.

No había un orden obligatorio de campos, separadores, precisión fraccionaria, año de cuatro dígitos, relación con UTC, idioma, representación de segundos intercalares ni indicador de calidad del reloj. «Actual» era una afirmación del servidor. No equivalía a «sincronizada», «exacta» o «autenticada».

La diferencia ayuda a leer los registros de puertos. Un número de servicio común facilita que dos extremos sepan qué aplicación esperan. No convierte al operador en autoridad civil del tiempo ni resuelve la ambigüedad de una abreviatura de zona.

La máquina tenía otro protocolo

La nota final de RFC 867 decía dónde buscar tiempo útil para máquinas: RFC 868. Time devolvía en el puerto 37 un entero sin signo de 32 bits que contaba segundos desde el inicio de 1900. Daytime ofrecía una línea legible en el 13; Time, una cantidad fija en el 37.

Esta indicación impide juzgar Daytime como una serialización incompleta. El límite era intencional. Un operador podía conectarse con una herramienta elemental, comprobar que el host contestaba y ver su reloj. La aplicación que necesitaba cálculo debía utilizar el contrato numérico vecino.

En octubre de 1983, RFC 880 clasificó Daytime como «elective»: un host podía implementarlo o no. Clasificó Time como «recommended»: se alentaba su implementación general. La categoría histórica no demuestra cuántos servidores existen hoy, pero sí muestra que la lectura humana y el valor de máquina ocupaban papeles distintos.

Tampoco conviene idealizar Time. Su número fijo resolvía la forma de intercambio, no la presentación humana ni todos los problemas futuros de era. Esta pieza no repite el problema NTP de 2036; utiliza RFC 868 solamente como el contraste que RFC 867 ordenó.

Un martes que debía ser lunes

El primer ejemplo de Daytime asignó originalmente martes al 22 de febrero de 1982. Ese día fue lunes. El RFC Editor verificó en 2025 el erratum 8551 y corrigió la palabra. Fue una reparación editorial, no un cambio del protocolo y tampoco una medición de implementaciones.

Su importancia es más pequeña y más precisa. El ejemplo contenía dos expresiones del mismo hecho: fecha de calendario y día de la semana. La redundancia permitió una contradicción. Una persona puede sospechar del error; un programa necesita una regla para decidir cuál campo manda. RFC 867 no tenía esa regla porque nunca quiso definir el análisis.

RFC 3339 describió más tarde exactamente este riesgo para las marcas temporales de Internet. Excluyó el día de la semana porque puede dejar de coincidir con la fecha, exigió años de cuatro dígitos y requirió una relación expresa con UTC mediante un desplazamiento numérico o Z. También señaló los problemas de las abreviaturas alfabéticas de zona.

No existe una sucesión normativa entre ambos documentos: RFC 3339 no sustituyó a Daytime, ni nació de aquel erratum. La comparación revela dos soluciones. Daytime permitía al servidor presentar. RFC 3339 fijaba una representación de intercambio para que cada cliente presentara después según su localidad.

Cuando la salida humana se convierte en API clandestina

La legibilidad reduce el coste de depurar. RFC 3339 lo reconoce. Pero una fecha natural para un país puede ser ambigua en otro. Por eso una arquitectura internacional no puede hacer del formato de pantalla su único formato de datos.

Daytime funcionaba mientras el destinatario fuera una persona. El problema aparece cuando un script captura la línea, una expresión regular se adapta a un servidor y un panel conserva solo el resultado normalizado. Sin anuncio formal, la puntuación y las palabras del operador se convierten en una API.

Si el servidor pasa de una zona alfabética a otra presentación, puede seguir siendo plenamente conforme a RFC 867 y romper al consumidor. El fallo no demuestra mala conducta del servidor. Demuestra que el cliente convirtió una observación local en una garantía que nunca recibió.

La automatización responsable necesita otro acuerdo: conservar la línea como evidencia opaca o definir de forma explícita una sintaxis, una zona y un comportamiento ante errores. «Lo hemos podido analizar hasta ahora» no es una propiedad del estándar.

IANA asigna un nombre, no una obligación de exposición

IANA mantiene daytime para TCP y UDP en el puerto 13 con referencia a RFC 867. El registro conserva el significado del espacio de nombres. No acredita despliegue, seguridad, exactitud ni legitimidad del tráfico, y no obliga a mantener el servicio accesible desde Internet.

La modalidad UDP añade una decisión operacional. Contesta sin interpretar la consulta y la dirección IP de origen puede falsificarse. RFC 8085 advierte de manera general que una solicitud breve y no autenticada que provoca una respuesta mayor puede participar en amplificación, y recomienda limitar o autenticar respuestas según el caso. Las fuentes no cuantifican abuso actual de Daytime ni un factor universal.

Un operador debe justificar la superficie expuesta. Establecer TCP no autentica el reloj. Recibir UDP no autentica al solicitante. Mostrar una frase clara no convierte el contenido en evidencia confiable de tiempo.

La lección de una norma que supo detenerse

RFC 867 hizo predecible la conversación mínima y dejó libre la presentación. Para un diagnóstico humano, esa combinación tenía sentido. El límite solo se vuelve peligroso cuando un tercero le atribuye una promesa que el documento negó.

Es posible escribir un analizador para cualquier respuesta concreta. La cuestión es si la norma autoriza a esperar que funcione con todos los servidores conformes. En Daytime, no lo hace.

La interoperabilidad, por tanto, no es indivisible. Dos hosts pueden coincidir en el puerto y discrepar en la gramática. Una línea puede respetar ASCII y seguir siendo ambigua. El servidor puede cumplir mientras el proceso automático falla. Conocer el límite de una norma es tan importante como conocer sus campos.

Fuentes y límites de evidencia

El contrato original está en RFC 867 y la corrección del ejemplo en el registro de erratas. El contraste de máquina procede de RFC 868 y la clasificación histórica de RFC 880.

RFC 3339 aporta la comparación posterior; RFC 6335 y el registro IANA delimitan el puerto; RFC 8085 delimita el uso moderno de UDP. Estas fuentes no miden uso, precisión ni ataques actuales.