5.5.1 Fecha y hora en C/C++
§1 La cuestión del tiempo (fecha y hora)
El tiempo cronológico (fecha y hora) ha sido incumbencia de la informática casi desde su nacimiento; en especial cuando salió de los nichos académicos y de investigación en que había nacido, e irrumpió en el ámbito empresarial. Cuando comenzaron a utilizarse las denominadas aplicaciones "comerciales" o de "gestión". Ni que decir tiene que los fenómenos de globalización (Internet y grandes redes), han reforzado aún más un tratamiento correcto y homogéneo de estas variables.
Nota: desafortunadamente no existe en español una palabra para designar el tiempo cronológico de forma completa. El "tiempo" es un concepto abstracto que también puede referirse al estado atmosférico. La "fecha" solo se refiere a mes, día y año, y la "Hora", solo a hora, minutos y segundos. En informática se utiliza a veces el vocablo timestamp (proveniente del mundo Unix) como una forma genérica de designar el tiempo cronológico de forma completa: fecha; hora; minutos y segundos.
Desde el punto de vista informático, las cuestiones de fecha y hora (timestamp) comprenden varias facetas:
Mantenimiento de un sistema de cronometraje adecuado en el sistema, de forma que pueda conocerse la hora en un momento dado, o la diferencia de tiempo entre dos sucesos. Este servicio lo realiza el denominado reloj de tiempo real RTC ("Real Time Clock"), que proporciona un "timestamp" local o "del sistema" . Es frecuente que las aplicaciones puedan interrogar a este dispositivo y aplicar la respuesta en sus propios procesos. Por ejemplo, incluir fecha y hora en un mensaje de Internet o en una factura.
Almacenamiento de la información correspondiente a un instante dado (por ejemplo el momento de inicio de una transmisión de Internet). Precisamente una imprevisión originada en los primeros años de la informática de "gestión" fue el origen del problema del año 2000 (Y2K), que en su momento mantuvo en vilo a la comunidad internacional ( A.1).
Por supuesto, no es lo mismo almacenar el año de nacimiento de un paciente en una historia clínica, que el "timestamp" de una transacción electrónica (cuando sacamos dinero de un cajero automático). En este caso, cualquiera que sea el sistema y lenguaje de programación utilizado, debemos asegurarnos de almacenar la fecha (año con cuatro dígitos, mes y día) y hora (por lo menos hora y minuto). Naturalmente, las necesidades de almacenamiento (espacio en bytes) serán distintas en uno y en otro caso. A este respecto existen diversos trucos y cada programador puede adoptar la convención que mejor le parezca. Por ejemplo, algunos sistemas guardan los "timestamp" como un número que representa los segundos transcurridos desde el inicio de la época UNIX (1 de Enero de 1970 00:00:00 GMT).
-
La forma de representación (para el humano que debe interpretarla). Existen tantas posibilidades como pueda inventar un programador, pero algunos formatos son estándar o más usuales. Además existen diferencias culturales (lo que en programación se denominan localismos 5.2). Por ejemplo, en España la fecha es generalmente representada en la forma día-mes-año (dd-mm-aa). Mientras que en USA es más frecuente representarla como aa-mm-dd. El año puede representarse con dos o cuatro dígitos, Etc.
Son frecuentes los siguientes formatos:
Sun, 06 Nov 1994 08:49:37 GMT
Sunday, 06-Nov-94 08:49:37 GMT
Sun Nov 6 08:49:37 1994El primero es el más utilizado en Internet (una versión de longitud fija del estándar RFC 1123). El segundo es también muy utilizado, aunque se basa en un estándar obsoleto que representa el año solo con dos dígitos. El tercero corresponde a la función asctime( 5.5.1a) del ANSI C. Las normas ISO establecen que la fecha debe representarse en la forma aaaa-mm-dd (el símbolo de separación puede variar o no existir aaaammdd), y que la hora debe expresarse mediante un reloj de 24h en la forma hh:mm:ss. También puede variar el signo de separación, no existir: hhmmss, u omitirse los segundos: hhmm.
-
Formato utilizado para la transmisión de este dato entre sistemas. El algoritmo debe ser conocido en ambos extremos de las transmisión para que pueda ser correctamente interpretado.
-
La coordinación y manejo de la fecha/hora en los diferentes puntos del planeta, o de una WAN; asunto este que tratamos en el siguiente epígrafe.
En los modernos sistemas de redes (WAN), es vital el mantenimiento de un sistema de cronometraje homogéneo, de forma que los actuales SOs de Red disponen de recursos para que determinados servidores (patrones de dominio) actúen como referencia horaria del resto de nodos.
§1.1 GMT
GMT es el acrónimo de "Greenwich mean Time". Literalmente tiempo medio de Greenwich. Es la hora estándar de dicho observatorio del Reino Unido próximo a Londres.
El asunto tiene su origen en que como todos sabemos, la tierra da vueltas sobre su eje frente al Sol, de forma que las zonas iluminadas y en sombra van cambiando a lo largo del día. Precisamente la sucesión de días; la duración de los periodos de luz/sombra y la posición del Sol, han sido la base de la medida del tiempo desde la más remota antigüedad. En realidad el asunto no tendría que presentar inconveniente; todo el mundo podría adoptar el mismo patrón horario y por ejemplo, las 12 del medio día fuese el mismo instante en todo el planeta. El problema es que precisamente entonces, a las 12 en unos sitios sería efectivamente el medio día (el sol en su cenit); en otros estaría anocheciendo; en otros amaneciendo y en otros "media noche". Como todo el mundo quiere que a las 12 sea efectivamente "medio día", la única solución es que la hora (y por consiguiente la fecha) no pueda ser uniforme en todo el mundo.
Nota: la página adjunta contiene un applet Java que muestra gráficamente el paso de la luz/penumbra/sombra por las distintas zonas del globo ( SunClock).
En vista del problema, para tener un punto de referencia común para la hora en todo el planeta, por recomendación de la Unión Astronómica Internacional, en 1928 se adoptó el sistema GMT de medición del tiempo. El sistema estableció una división del planeta en 24 usos horarios de 15 grados (360/24) que tienen la misma hora en todos sus puntos. Estos usos están separados por meridianos (círculos máximos que pasan por los Polos) a partir del meridiano 0 que es del de Greenwich.
Los usos horarios hacia el Este (+) y hacia el Oeste (-) de Greenwich convergen en el meridiano 180, denominado línea internacional del tiempo porque la fecha cambia sobre este meridiano, propagándose sobre el resto de Este a Oeste en función de las diferencias de cada uso.
Nota: el sentido de rotación de la tierra sobre su eje es Oeste a Este, de modo que el movimiento aparente del Sol es al contrario. Justamente por esta razón, en español denominamos "Levante" al Este y "Poniente" al Oeste. Las longitudes geográficas se cuentan en grados a partir del meridiano 0, y se consideran positivas hacia el Este y negativas hacia el Oeste. De modo, que la longitud de la ciudad de Roma (al Este de Greenwich) es positiva, y la de islas Azores (al Oeste) negativa.
Por razones de
tipo práctico. Por ejemplo, que un país pequeño tenga la misma hora aunque quede a caballo de dos meridianos, se realizaron
determinados ajustes siguiendo fronteras nacionales y divisiones
administrativas. De forma que las zonas horarias que determinan la hora local (civil) siguen, aunque no exactamente, el
reparto en usos horarios. La línea internacional de cambio de fecha es la adaptación práctica de la
línea del tiempo y sigue aproximadamente a aquélla a través del Océano
Pacífico, al Este de Nueva Zelanda y al Oeste de las islas Samoa [2].
Nota: a pesar de los ajustes anteriores, algunos países extensos como USA o la Federación Rusa, tienen distintas zonas horarias dentro de su territorio. Por ejemplo, aparte de las zonas de Alaska y Hawaii, la zona continental USA tiene cuatro horarios distintos: Eastern (GMT-5); Central (GMT-6); Mountain (GMT-7) y Pacific (GMT-8).
Cada uso horario está representado por una letra. La "Z" para el de Greenwich (del inglés "zero"). A partir de ahí, hacia el Este van recibiendo sucesivamente las letras "A", "B", "C", Etc. hasta la "M", que corresponde aproximadamente con el meridiano 180º. Hacia el Oeste se utilizan las letras "N", "O", ..."Y". Cada letra tiene asignado un número positivo (letras del Este) o negativo (letras del Oeste) que indica la diferencia en horas respecto al meridiano 0.
A B C D E F |
+1 +2 +3 +4 +5 +6 |
G H I K L M |
+7 +8 +9 +10 +11 +12 |
N O P Q R S |
-1 -2 -3 -4 -5 -6 |
T U V W X Y |
-7 -8 -9 -10 -11 -12 |
A partir del meridiano 0 hacia la derecha (Este), los usos horarios son GMT+ n, y hacia la izquierda (Oeste) los usos horarios son GMT - n. De esta forma, el cálculo de hora local LST ("Local Standard Time" ) de cualquier punto geográfico, se reduce a conocer la hora GMT y sumarle o restarle un entero n que corresponde al desfase de su uso horario [5].
Nota: los usuarios de Sistemas Windows pueden comprobar (Panel de Control Fecha y hora [3] ) que, por ejemplo, Dublín, Edimburgo, Lisboa y Londres tienen hora local GMT; mientras que Moscú o San Petesburgo (situadas al Este) pertenecen al uso horario GMT+3; y México DF (situada al Oeste), al uso GMT-6. Por su parte la hora de la costa Oeste USA es GMT-8 y la mayor parte de la CE es GMT+1 [1].
Si es usuario de Linux puede utilizar el comando tzselect. Un menú le irá preguntando por su situación geográfica en el mundo. Al final, en base a la información del RTC del sistema, le informará de su hora local y de la hora universal correspondiente. Por ejemplo, en un momento dado, tras contestar las preguntas correspondientes, mi sistema produce la siguiente salida:
Local Time is now: Wed Nov 9 00:45:49 CET 2005
Universal Time is now: Tue Nov 8:23:45:49 UTC 2005
§1.2 UTC
En 1972 el sistema GMT pasó a denominarse Tiempo Universal Coordinado UTC ("Universal Time Coordinated"), aunque la nueva denominación convive con la antigua (la Librería Estándar C++ utiliza la denominación primitiva). Así pues, la hora GMT (hora del meridiano 0) es la hora UTC, que es proporcionada por numerosas estaciones de radio y por el sistema GPS de posicionamiento global por satélite.
Cuando se utiliza la hora UTC se suele indicar añadiéndole una "Z", para indicar que es la hora referida al meridiano de longitud cero ("Zero"). Por ejemplo: 12:23:45z indica que es la hora de Greenwich. Como en el alfabeto internacional de radio la "Z" se pronuncia "Zulú", es frecuente que la hora UTC sea denominada "hora zulú".
§1.3 LST
Hora local estándar LST("Local Standard Time") corresponde a la hora del uso horario local (LST = GMT +/- n). La fecha y hora del sistema (ordenador) se ajustan para que coincidan con la LST del sitio donde está instalado el equipo.
§1.4 DST
Con el fin de ajustar la actividad humana con la luz solar, en determinados países, la hora LST correspondiente al uso horario puede verse corregida con adelantos de una hora al llegar a ciertas épocas del año (al llegar a otras épocas se pierde el adelanto ganado) [4]. Esta nueva hora se denomina tiempo de aprovechamiento de luz diurna, mucho más corto en su denominación inglesa DST "Daylight saving time" o simplemente "horario de verano" en la mayoría de países. De forma que: DST = LST + 1/0 = GMT +/- n + 1/0. El DST no sigue reglas fijas y está supeditado a las decisiones de la autoridad política. Por ejemplo, en Brasil la hora DST es establecida cada año mediante un decreto presidencial, e incluso dentro de un mismo país, el criterio puede cambiar a lo largo de los años debido a estados de guerra, crisis energéticas etc.
Ejemplo: España (excepto las islas Canarias) está en el uso horario "A", también conocido como CET ("Central Europe Time"), por lo que LST = GMT+1. En invierno el DST coincide con LST, pero en verano el tiempo DST tiene una hora de adelanto, de forma que DST = GMT+2.
Nota: es una práctica universal que las comunicaciones en Internet no utilicen la hora local del transmisor, sino la hora Zulú (UTC). Cuando no se hace así y se utiliza la hora local, se añade indicación del uso horario del remitente y si utiliza DST. Por ejemplo: Tengo un mensaje que en las cabeceras internas aparece como enviado:
Date: Sat, 17 May 2003 10:05:06 -0700 (PDT)
lo que indica que ha sido enviado el sábado 17 de Mayo del 2003 a las 10:05:06 desde algún punto (de la costa Oeste USA) que utiliza el horario PDT ("Pacific Daylight Time"). El horario "Pacific" PST tiene un retraso de 8 horas sobre Greenwich, que se reduce a 7 en verano. Por mi parte, aunque mi LST habitual es GMT+1, en verano estoy en GMT+2, por lo que nos separan 9 horas. Esta es la razón por la que en mi cliente de correo aparece: Enviado 17-05-03 19:05, ya que es la hora española en el momento del envío. A su vez, el último salto "Hop" del mensaje por los servidores de correo demuestra que fue recibido en algún servidor que utiliza hora zulú (quizás en el Reino Unido) con la indicación:
Received: 17 May 2003 16:01:31 -0000
Como he indicado, mi cliente de correo es muy atento (quiere que sepa a que hora local fue recibido) y sabe que mi horario de verano es GMT+2, así que le añade dos horas y me indica: Recibido: 17-05-03 18:01. Resulta así que por obra de los misterios del tiempo (un servidor mal configurado) he conseguido recibir un correo casi una hora antes de haber sido enviado!!.
Generalmente, las combinaciones de horas locales con y sin aplicación de DST
se identifican mediante abreviaturas. Cuando se indica "daylight
time" se refiere al horario de verano que está adelantado 1 hora
respecto al de invierno (muchas zonas mantienen el mismo horario todo el
año). Las abreviaturas más utilizadas son las siguientes:
Europa: |
USA y Canadá: |
||
GMT Greenwich Mean Time BST British Summer Time IST Irish Summer Time WET Western Europe Time WEST Western Europe Summer Time CET Central Europe Time CEST Central Europe Summer Time EET Eastern Europe Time EEST Eastern Europe Summer Time MSK Moscow Time MSD Moscow Summer Time |
UTC+0 UTC+1 UTC+1 UTC+0 UTC+1 UTC+1 UTC+2 UTC+2 UTC+3 UTC+3 UTC+4 |
NST Newfoundland Standard Time NDT Newfoundland Daylight Time AST Atlantic Standard Time ADT Atlantic Daylight Time EST Eastern Standard Time EDT Eastern Daylight Saving Time CST Central Standard Time CDT Central Daylight Saving Time MST Mountain Standard Time MDT Mountain Daylight Saving Time PST Pacific Standard Time PDT Pacific Daylight Saving Time AKST Alaska Standard Time AKDT Alaska Standard Daylight Saving Time HST Hawaiian Standard Time |
UTC-3:30 UTC-2:30 UTC-4 UTC-3 UTC-5 UTC-4 UTC-6 UTC-5 UTC-7 UTC-6 UTC-8 UTC-7 UTC-9 UTC-8 UTC-10 |
Australia: |
|||
AEST
Australian Eastern Standard Time AEDT Australian Eastern Daylight Time ACST Australian Central Standard Time ACDT Australian Central Daylight Time AWST Australian Western Standard Time |
UTC+10 UTC+11 UTC+9.5 UTC+10.5 UTC+8 |
Ejemplo: si deseo asistir a un webminar [6] que tendrá lugar en Boston, el 19 de Octubre de 2005 a las 14 horas. Se que debo conectar con la URL correspondiente el mismo día a las 20 horas, ya que mi horario en España es CEST (UTC+2) y el de Boston, que tiene hora EDT (UTC-4), lo que corresponde a 6 horas de diferencia (mi hora local está adelantada respecto a la de Boston).
Nota: además de las anteriores existen otros sistemas horarios:
- UT ("Universal Time"). Tiempo universal utilizado en astronomía. Los sistemas GMT o UTC son sistemas civiles; UT es un sistema científico que tiene en cuenta el movimiento "real" de rotación de la tierra que no es absolutamente constante.
- TAI ("Time Atomic International") Sistema de tiempo basado en relojes atómicos. Proporciona una definición del segundo basado en magnitudes de física atómica totalmente independientes de consideraciones de mecánica celeste.
§1.5 TAI
TAI es el acrónimo del francés "Temps Atomique International" (tiempo atómico internacional). Es un sistema de medida del tiempo utilizado por los científicos, lo que viene a significar que es el más fiable y preciso disponible en la actualidad. El día TAI está compuesto por 86.400 segundos (vaya novedad, pensará alguno). La novedad es que como hemos visto, hasta 1967, la medición del tiempo y por tanto del segundo, se basaba en medidas astronómicas relativas a la rotación de la tierra alrededor de su eje, con el inconveniente de que esta rotación no es constante. En consecuencia, la comunidad científica internacional decidió basar la medida del tiempo en un patrón más fiable. Para ello se definió el segundo atómico internacional como la duración de 9,192,631,770 periodos de la radiación emitida por el átomo de cesio-133 al pasar entre dos niveles determinados de energía. La medida de esta radiación es la base de los relojes atómicos.
La medida del tiempo TAI se inició a las cero horas del 1 de Enero de 1958. En cuyo instante coincidió con el tiempo UTC. Como los días TAI son constante y el tiempo UTC no lo es, se van produciendo disparidades entre lo que indican los relojes atómicos y las mediciones astronómicas. Por ejemplo, el instante en que el Sol pasa por su cenit en Greenwich. Puesto que nuestras vidas están muy influenciadas por el Sol, la solución adoptada ha consistido en ir ajustando los relojes atómicos con saltos de un segundo, denominados "second leap", para que se ajusten al tiempo UTC. Así pues, nuestra vida cotidiana está regida por relojes atómicos con "correcciones". Es lo que se denomina UT1 (tiempo atómico ajustado a UTC).
Nota: en 1972 se produjo el primero de estos ajustes especiales. Desde entonces se han producido 23 ajustes hasta la fecha (2006). En realidad, el retraso acumulado por el tiempo UTC respecto del tiempo TAI es de 33 segundos desde la instauración de este último en 1958.
§2 El tiempo en el Sistema
Los ordenadores modernos mantienen un reloj de tiempo real RTC ("Real Time Clock") materializado en un dispositivo hardware (generalmente un oscilador controlado por cuarzo). A su vez, el Sistema Operativo puede obtener datos relativos a intervalos de tiempo y de fecha y hora (timestamp )en base a la información proporcionada por este dispositivo. En los sistemas monousuario (tipo MS-DOS) esta información puede ser accedida directamente desde las aplicaciones consultando un puerto determinado. En los sistemas multiusuario (tipo MS-Windows), mediante un controlador que virtualiza el dispositivo ("Virtual Timer Device" 0.2) para cada una de las aplicaciones que corre en el Sistema.
En principio el timestamp mantenido por el RTC debe corresponder con la hora local LST del sitio donde se encuentra instalado el ordenador. A su vez el SO mantiene información sobre otros detalles como el uso horario correspondiente y si son de aplicación las correcciones DST de aprovechamiento de luz diurna.
Nota: Los usuarios de SOs Windows en países donde se utilizan correcciones DST habrán observado como en determinados momentos el sistema avisa que ha ajustado la hora al horario de verano o de invierno.
Para entender los aspectos relativos a fecha y hora de las
funciones de la Librería Estándar, el programador C++ debe tener en cuenta que estas
funciones obtienen su información mediante llamadas al RTC, y que para obtener la hora oficial, el valor
obtenido del reloj es modificado en función de ciertas variables globales mantenidas por el compilador
(
4.1.3a). Estos valores son establecidos como
parte de las rutinas de inicio del programa en función de cierta información
proporcionada por el Sistema Operativo, aunque pueden ser cambiados por el usuario.
Los detalles no están estandarizados y dependen de la plataforma. En el caso de los compiladores Borland C++ y MS Visual C++, las variables que controlan estos aspectos de la hora del sistema son las siguientes:
-
_timezone ( 4.1.3a) que contiene la diferencia de tiempo en segundos entre la hora GMT y la hora local. Es utilizada por algunas funciones de hora/fecha de la RTL.
-
_daylight ( 4.1.3a). Valor utilizado por las funciones de la RTL relacionadas con la fecha y la hora, por ejemplo mktime( 5.5.1a) y localtime( 5.5.1a). Se trata de un entero que informa a dichas funciones cuando deben tener en cuenta los adelantos y retrasos DST.
-
_tzname ( 4.1.3a) es una matriz de dos punteros a carácter que señalan el uso horario y la zona de aprovechamiento de luz solar.
-
_tzname[0] El valor señalado por este puntero es un campo de tres caracteres numéricos (opcionalmente puede estar precedido de un signo) que representa la diferencia en horas de la hora de Greenwich con el uso horario local (GMT - LST).
_tzname[1] Señala un campo de tres caracteres que representa el DST. Por ejemplo, PDT representa el horario de verano en la zona del Pacífico. La presencia de este campo indica que hay horario de verano, y hace que _daylight adopte un valor distinto de cero y de cero en caso contrario.
-
Algunos sistemas utilizan una variable de entorno denominada TZ ("Time Zone"). Es una cadena alfanumérica de longitud variable que tiene el formato: XXX[+/-]n[n][zzz].
-
XXX son tres caracteres que señalan el nombre del uso horario. Por ejemplo PST para designar la hora estándar del Pacífico.
-
[+/-]n[n] es un número de uno o más dígitos (opcionalmente precedido de un signo) que representa la diferencia GMT - LST. Este valor es utilizado para el cálculo de la variable _timezone y está contenido en _tzname[0]. Ejemplo: A la hora "Pacific" le corresponde +8; a la hora "Eastern" 5, y a la hora de Europa continental -1.
-
zzz es un campo opcional de tres caracteres que representa el DST. Este valor está indicado por _tzname[1].
Ejemplo: TZ="PST8PDT" Hora estándar del pacífico (8 horas de diferencia con la hora de Greenwich) con aprovechamiento de luz diurna.
En Borland C++, si la cadena ST no existe, o no tiene el formato adecuado, el sistema asume por defecto el valor TZ = “EST5EDT” para asignar valores a las citadas variables (corresponde con un uso horario denominado "Eastern" en USA y Canadá con aprovechamiento de luz diurna). En los SO Win32 ninguna de estas variables globales es iniciada si TZ es una cadena nula.
Aunque no se trata de una utilidad de la Librería Estándar C++, en los sistemas Win32, UNIX y XENIX es posible establecer el valor de TZ mediante la función tzset() de <time.h>, que como hemos señalado, tiene influencia en las mentadas variables globales _timezone, _daylight y _tzname que a su vez influyen en las rutinas de la Librería.
Ejemplo (la explicación de las funciones utilizadas se incluye más adelante):
time_t tAct = time(NULL);
cout << "Tiempo actual: " << asctime(localtime(&tAct));
putenv("TZ=PST8PDT");
tzset();
cout << "Tiempo actual: " << asctime(localtime(&tAct));
Salida:
Tiempo actual: Fri May 23 12:10:04 2003
Tiempo actual: Fri May 23 03:10:04 2003
Ejemplos relacionados: 4.5.5c; 4.9.6; 9.1
§3 Webografía
- W3C www.w3.org
Si está interesado en estos aspectos del tiempo (fecha y hora), una buena referencia, y punto de inicio para ampliar conocimientos, es la página "World Time" del W3C.
[1] El caso de España es muy ilustrativo. Su hora local es GMT+1, aunque por su longitud geográfica (aproximadamente la misma que el Reino Unido) debería tener hora Zulú (GMT+0). Sin embargo, al ser uno de los países más meridionales de Europa, se ha preferido "adelantar" de forma permanente el horario en una hora para aprovechar mejor la luz diurna. Este desfase resulta de 2 horas cuando se aplica el horario de verano que incluye otra hora de adelanto.
[2] Muchos recordarán que, en las transmisiones de Fin de Año, la televisión nos informa que el primer sitio en recibir el nuevo año son unas remotas islas del Pacífico (a mí me lo parecen :-).
[3] El directorio TOOLS\RESKIT\CONFIG del CD de distribución de Windows98 2E, contiene un programa, Tzedit.exe, que permite editar estas zonas horarias (incluso incluir otras nuevas).
[4] A pesar de sus supuestas ventajas, la medida es objeto de muchas controversias.
[5] Algunos países tienen horarios que se diferencian en 30 minutos con el que les correspondería por su posición geográfica. En estos casos la letra se acompaña con un asterisco. Por ejemplo India está en el uso E* cuyo horario es GMT+5.30.
[6] Seminario o conferencia Web a la que puede asistirse mediante el navegador. Algunos eventos permiten intervenir y realizar preguntas al ponente, ya que el sonido se transmite mediante VoIP (Voice over Internet Protocol). Este tipo de seminarios suele requerir una inscripción previa. A título de curiosidad y ejemplo del método utilizado, incluyo un extracto del e-mail recibido confirmando la inscripción (creo que, en el próximo futuro, la enseñanza se impartirá por estos métodos).
Asunto: Procesamiento de señales con múltiples frecuencias de muestreo en ... |