El protocolo TIME está especificado en la RFC 868. Es necesario desarrollar un programa que cumpla con las especificaciones de dicho documento y ciertas consideraciones adicionales que serán descritas a continuación.

El programa a desarrollar podrá funcionar en dos modos: modo consulta y modo servidor:

-En modo consulta, el programa debe seguir el flujo de operación de un cliente TIME sobre TCP o sobre UDP, dependiendo de los parámetros de ejecución. 

En el caso de ejecución como cliente UDP, el programa operará tal y como se describe en la RFC, es decir: enviará un datagrama vacío al servidor y obtendrá la respuesta. 

En el caso de arranque como cliente TCP, el programa tendrá el comportamiento descrito en la RFC pero con una ligera modificación: no cierra la conexión inmediatamente después de obtener la hora del servidor, sino que se queda escuchando actualizaciones de la hora hasta que el usuario envía una señal SIGINT para finalizar el programa. En ambos casos, la fecha y hora obtenidas deberán mostrarse por pantalla siguiendo el formato que se detalla más abajo en el apartado de "Ejemplos y trazas".

-En modo servidor, el programa deberá funcionar como un servidor TIME sobre TCP de la siguiente manera: cada vez que un cliente se conecte, el servidor le enviará la hora (obtenida de su sistema local) cada segundo hasta que el cliente decida cerrar la conexión.

-Ejecutable y parámetros: el ejecutable se llamará atdate y debe soportar los siguientes parámetros: atdate [-h serverhost] [-p port] [-m cu | ct | s ] [-d]

    -h serverhost: nombre del servidor TIME al que se conectará el programa para obtener la fecha y hora actual. Este argumento es obligatorio sólo si el programa se lanza en modo consulta, es decir, con -m cu o -m ct.
    -p port: para indicar que el servidor TIME al que nos conectamos escucha en un puerto diferente al 37. El puerto por defecto es el 37. 
    -m: para indicar el modo de ejecución del programa:

            cu: el programa arranca en modo consulta funcionando como cliente UDP.
            ct: el programa arranca en modo consulta funcionando como cliente TCP.
            s: el programa arranca en modo servidor.

Si no se especifica la opción -m, el programa arranca en modo consulta UDP, es decir: -m cu.

    -d: modo depuración. Mostrará trazas adicionales para la depuración del programa.

Si alguno de los parámetros opcionales necesarios para la ejecución no se proporciona por línea de comandos, se tomarán los valores por defecto.

Ejemplos y trazas:

    Modo consulta UDP:

    monitor01:~> atdate -h time-a.timefreq.bldrdoc.gov -m cu
    Mon Feb 7 19:45:31 CET 2016

    Modo servidor:

    monitor01:~> atdate -m s
    TIME server running in port 6001

    Modo consulta TCP:

    Nos conectamos al servidor lanzado en el paso anterior ejecutando otra instancia del programa en modo consulta TCP:

    monitor02:~> atdate -h monitor01.lab.it.uc3m.es -p 6001 -m ct
    Mon Feb 7 19:46:12 CET 2016
    Mon Feb 7 19:46:13 CET 2016
    Mon Feb 7 19:46:14 CET 2016
    Mon Feb 7 19:46:15 CET 2016

    SIGINT received, closing program

-Notas y aclaraciones a la RFC:

1.En modo servidor, el programa escuchará en el puerto 6000+3 últimos dígitos de su NIA. El servidor debe ser concurrente.
2.Para trabajar con los datos relativos a las fechas pueden ser útiles las siguientes funciones: time(2), strftime(3).
3.Tenga en cuenta a la hora de procesar las fechas que la "Época" de Unix es diferente a la tomada como referencia en el protocolo TIME. En el primer caso es el 1 de Enero de 1970, mientras que en el segundo caso, se utiliza el 1 de Enero de 1900.
4.Existen multitud de servidores de hora en Internet que implementan el protocolo TIME que pueden ser usados para probar el correcto funcionamiento de su programa. A continuación listamos algunos ejemplos, puntualmente algunos de ellos pueden no estar disponibles:

        time-a.timefreq.bldrdoc.gov
        time-b.timefreq.bldrdoc.gov
        time-c.timefreq.bldrdoc.gov
        utcnist.colorado.edu
        ntps1-2.uni-erlangen.de
        time.ien.it
        ptbtime2.ptb.de
5.Es recomendable realizar pruebas con el cliente rdate (man rdate para más información) instalado en aulas para comprender bien el protocolo antes de proceder con la implementación. El análisis de tráfico con tcpdump puede ser de gran ayuda en esta tarea. Un ejemplo de ejecución de rdate preguntando al servidor time-a.timefreq.bldrdoc.gov sería:

    monitor01:~> rdate -u -p time-a.timefreq.bldrdoc.gov
    Tue Sep  4 09:09:38 CEST 2018
6.No es necesario que el programa fije la fecha en el sistema local, es suficiente con mostrarla por pantalla.