Tiempo

Convertir una hora de cadena a/desde una hora numérica

En varios lugares de ERDDAP, un momento en el tiempo se puede representar como:

Una cadena : ERDDAP siempre utiliza el formato "extended" ISO 8601:2004 yyyy-MM-ddTHH:mm:ssZ - por ejemplo, 2018-01-02T00:00:00Z . Los conjuntos de datos fuera de ERDDAP suelen utilizar un formato diferente para los valores de tiempo de cadena.
Un número : al representar tiempos como números, ERDDAP siempre escribe un número compatible con UDUNITS - por ejemplo, n=473472000 unidades = "seconds since 1970-01-01T00:00:00Z" . ERDDAP utiliza esa cadena de unidades exactas para todos los conjuntos de datos. Los conjuntos de datos fuera de ERDDAP suelen utilizar cadenas de unidades diferentes.

Esta página web tiene conversores que pueden cambiar valores de tiempo de cadena (con varios formatos) a/desde valores de tiempo numéricos (con cadenas de varias unidades). También tiene conversores para cambiar cadenas de tiempo y cadenas de unidades que usan otros formatos a los formatos utilizados por ERDDAP .

Para evitar confusión entre zona horaria y horario de verano, los valores horarios en ERDDAP siempre utilizan la zona horaria Zulu (UTC, GMT), indicada por 'Z'. Los convertidores siguientes aceptan cadenas de horas con otras zonas horarias.

Restablezca el formulario a los valores predeterminados.

O bien, omita esta página web y realice conversiones desde un programa de computadora, script o página web.

Notas sobre el conversor de hora

RENUNCIA DE RESPONSABILIDAD : Ninguna persona u organización asociada con este sitio web ofrece ninguna garantía, expresa o implícita, incluidas garantías de comerciabilidad e idoneidad para un propósito particular, ni asume ninguna responsabilidad legal por la exactitud, integridad o utilidad de cualquier información contenida en este sitio. sitio web.
IMPERFECTO : estos convertidores son imperfectos. Siempre verifique los resultados de estos convertidores.
Estos convertidores aceptan una gran cantidad de formatos de tiempo de cadena, pero siempre habrá formatos que no reconocen o interpretan de manera diferente a como lo haría usted. En algunos casos, hay dos o más formas comunes, pero diferentes, de interpretar un formato de hora determinado, en particular #/#/#: en los EE. UU. normalmente se pretende que sea mes/fecha/año, mientras que en la mayor parte de Europa eso Por lo general, se pretende que sea fecha/mes/año. En ese caso particular, ERDDAP interpreta el valor como mes/fecha/año.
Unidades de tiempo UDUNITS : Por ejemplo, "seconds since 1970-01-01T00:00:00Z" . La primera palabra puede ser (mayúscula o minúscula):
  ms, msec, msecs, millis, millisecond, milliseconds,
  s, sec, secs, second, seconds,
  m, min, mins, minute, minutes,
  h, hr, hrs, hour, hours,
  d, day, days,
  week, weeks,
  mon, mons, month, months,
  yr, yrs, year, or years .
Se requiere "since" .
Otro ejemplo es "hours since 0001-01-01" .
La cadena de tiempo puede tener cualquier formato. La parte de la fecha es obligatoria. La parte del tiempo es opcional. ERDDAP hará todo lo posible para leer el formato que usted proporcione. El formato recomendado es el formato "extended" ISO 8601:2004 yyyy-MM-dd THH:mm:ss.SSSZ, donde Z es 'Z' o un desplazamiento ±hh o ±hh:mm de la zona horaria Zulu /GMT. Si omite Z y el desplazamiento, se utiliza la zona horaria Zulu /GMT. Por separado, si omite .SSS, :ss.SSS, :mm:ss.SSS o Thh:mm:ss.SSS, se supone que los campos faltantes son 0.
Técnicamente, ERDDAP NO sigue el estándar UDUNITS al convertir valores de tiempo "years since" y "months since" a "seconds since" . El estándar UDUNITS define un año como un valor único fijo: 3,15569259747e7 segundos. Y UDUNITS define un mes como año/12. Desafortunadamente, la mayoría o todos los conjuntos de datos que hemos visto que utilizan "years since" o "months since" claramente pretenden que los valores sean años calendario o meses calendario. Por ejemplo, 3 "months since 1970-01-01" generalmente significa 1970-04-01. Por lo tanto, ERDDAP interpreta "years since" y "months since" como años y meses calendario, y no sigue estrictamente el estándar UDUNITS .
Precisión del convertidor : al representar tiempos como números, este convertidor siempre deja los números con su máxima precisión. Al representar tiempos como cadenas, este convertidor formatea los tiempos al segundo (truncado) (es decir, omitiendo milisegundos).
Entrada no válida : ERDDAP intenta solucionar la entrada con formato incorrecto. Si ERDDAP no puede manejar la entrada, ERDDAP generará un mensaje de error. Si la "entrada no válida" es una cadena de tiempo que cree que debería admitirse, envíela por correo electrónico a erd dot data at noaa dot gov .

Cómo maneja ERDDAP el tiempo

El tiempo es una cuestión difícil, compleja y confusa.
Objetivo : un objetivo subyacente del sistema de ERDDAP para tratar con el tiempo es tener un sistema único que permita comparar los datos de tiempo de cualquier conjunto de datos directamente con los datos de tiempo de cualquier otro conjunto de datos. Tenga esto en cuenta cuando lea los otros comentarios a continuación.
Puntos de tiempo : ERDDAP solo trata con puntos de tiempo (una fecha y hora combinadas en la zona horaria Zulu, cada una de ellas un instante en el tiempo).
Zonas horarias : al escribir valores de hora, ERDDAP siempre utiliza la zona horaria Zulu (UTC, GMT) y nunca utiliza el horario de verano. Los datos de hora de una fuente con información de zona horaria (que puede incorporar información de horario de verano) se convierten a hora Zulu . Se supone que los datos de hora de una fuente sin información de zona horaria ya están en hora Zulu .
Precisión : ERDDAP trata el tiempo internamente como "seconds since 1970-01-01T00:00:00Z", ignorando los segundos intercalares, almacenados como números de coma flotante de doble precisión. Por lo tanto, la mayoría de los datos de tiempo se pueden almacenar con mucha precisión (aproximadamente al microsegundo más cercano, pero progresivamente con menos precisión en tiempos muy lejanos en el pasado o en el futuro).
Al realizar cálculos, ERDDAP suele trabajar al milisegundo más cercano, para evitar problemas con números de punto flotante que son ligeramente mayores o menores de lo esperado.
Al representar tiempos como números, ERDDAP siempre deja los números con total precisión.
De forma predeterminada, cuando se representan tiempos como cadenas, ERDDAP formatea los tiempos al segundo (truncado) (es decir, omitiendo milisegundos). Sin embargo, los administradores ERDDAP pueden configurar variables específicas en conjuntos de datos específicos para representar tiempos de cadena con otras precisiones (por ejemplo, desde precisión de milisegundos hasta precisión de mes; consulte el atributo de variable <time_precision> ). Siempre que no se muestra un campo de tiempo (por ejemplo, milisegundos o segundos), se supone que el valor ausente es 0 (excepto el día del mes, que se supone que es 1).
Unidades consistentes : el uso de las mismas unidades de tiempo ("seconds since 1970-01-01T00:00:00Z" ) para todos los conjuntos de datos permite comparar fácilmente los tiempos de diferentes conjuntos de datos. Los segundos son el Sistema Internacional de Unidades (SI) unidad base de tiempo. 1970-01-01T00:00:00Z es el comienzo de la era Unix, que es ampliamente utilizado por los sistemas operativos de computadoras. "seconds since 1970-01-01T00:00:00Z" se utilizan ampliamente y a menudo se denominan tiempo Unix. o segundos de época. El uso de la cadena de unidades "seconds since 1970-01-01T00:00:00Z" hace que la hora de Unix sea compatible con UDUNITS y las Convenciones sobre Metadatos (CF) sobre Clima y Pronósticos , que utiliza UDUNITS para definiciones de unidades.
Representación de texto : de forma predeterminada, al formatear tiempos como texto, ERDDAP utiliza la cadena de formato "extended" ISO 8601:2004. , truncado al segundo (por ejemplo, 2011-04-26T14:07:12Z). (Humor relacionado: https://xkcd.com/1179/ ) Los administradores ERDDAP pueden configurar una variable determinada para mostrar los valores de datos de tiempo con mayor precisión (truncados a 0,001 segundos, 0,01 segundos, 0,1 segundos) o con menor precisión (truncados a segundos, minutos, horas, fechas o meses) para indicar el precisión de los valores de los datos de tiempo.
Al leer ISO 8601 veces con segundos decimales, ERDDAP acepta un separador de punto (por ejemplo, 2011-04-26T14:07:12.059Z) o un separador de coma (por ejemplo, 2011-04-26T14:07:12,059Z). Actualmente, al escribir tiempos ISO 8601, ERDDAP siempre utiliza un separador de puntos.
Calendario Gregoriano - ERDDAP utiliza el Calendario Gregoriano para los tiempos posteriores a la discontinuidad en 1582 y el calendario juliano para los tiempos anteriores a la discontinuidad. (El estándar ISO 8601:2004 no especifica cómo manejar tiempos anteriores a 1582.) Consulte la clase Java GregorianCalendar (que utiliza ERDDAP ) para más detalles. Por ejemplo, 17611992 horas desde 0001-01-01T00:00:00Z = 2010-03-01T00:00:00Z (compruébelo usted mismo)
Actualmente, ERDDAP no admite ningún otro calendario (incluidos los calendarios noleap, 365_day, 360_day y Julian definidos por las convenciones de metadatos de CF). ). Sin embargo, puede almacenar dichos datos en ERDDAP almacenando los números o cadenas en una variable cuyo nombre no sea "time" y que no incluya "since" en los metadatos de las unidades. Entonces, ERDDAP no interpretará los valores como tiempos y no convertirá los datos a "seconds since 1970-01-01T00:00:00Z" . Los usuarios podrán acceder a los datos en su forma original.
Indulgente : ERDDAP es "indulgente" cuando analiza cadenas de fecha/hora. Eso significa que las fechas/horas con el formato correcto, pero con valores de mes, fecha, hora, minutos y/o segundos que son demasiado grandes o demasiado pequeños se trasladarán a las fechas/horas apropiadas. Por ejemplo, ERDDAP interpreta 2001-12-32 como 2002-01-01 e interpreta 2002-01-00 como 2001-12-31. (¡No es un error, es una característica! Entendemos que usted puede oponerse a esto si no está familiarizado con el análisis indulgente. Entendemos que hay circunstancias en las que algunas personas preferirían un análisis estricto, pero también hay circunstancias en las que algunas personas preferirían análisis indulgente. ERDDAP no puede tener ambas cosas. Esta fue una elección consciente. El análisis indulgente es el comportamiento predeterminado en Java, el lenguaje en el que está escrito ERDDAP y posiblemente el lenguaje informático más utilizado. La conversión de ERDDAP de los valores de eje de cuadrícula solicitados al valor de eje de cuadrícula válido más cercano y esto es consistente con algunos otros lugares en ERDDAP que intentan reparar entradas no válidas cuando la intención es clara, en lugar de simplemente devolver un mensaje de error).
Años BCE (BC) y numeración de años astronómicos: como se especifica en la norma ISO 8601:2004, ERDDAP solo utiliza la era común (CE, AD) para los números de años, no BCE. Para los años anteriores al 1 d.C., los historiadores usan la designación a.C. o a.C. y ningún año 0, por lo que su secuencia de años cerca de la transición de era es 2 a.C., 1 a.C., 1 d.C., 2 d.C. Durante años antes del año 1 a. C., la norma ISO 8601:2004 (según mi lectura) fomenta el uso de un sistema diferente: Numeración de años astronómicos. , en el que 1 a.C. se llama año 0000, 2 a.C. se llama año -0001, etc. Dado que la norma ISO 8601:2004 fomenta la numeración de años astronómicos y la utilizan muchos campos científicos, y porque los oceanógrafos y climatólogos suelen utilizar el año 0000 para las climatologías, ERDDAP utiliza numeración de años astronómicos. Por lo tanto, los años cercanos a la transición de era en ERDDAP son -0001, 0000, 0001, 0002, respectivamente. Por lo tanto, para los años BCE: AstronomicalYear = 1 - BCEYear (compruébelo usted mismo: prueba1, prueba2 y prueba3). Una ventaja de la numeración de años astronómicos es que todos los años bisiestos son divisibles por 4, por ejemplo, ..., -0008, -0004, 0000, 0004, 0008, .... Si recuerda utilizar números de años astronómicos, ERDDAP funcionará para fechas lejanas en el pasado y en el futuro.
La Red de Datos Marinos El proyecto almacena el tiempo como "días desde -4713-01-01T00:00:00Z", que es una referencia a la medianoche del inicio del 1 de enero de 4713 a. C., que es la hora de inicio de Chronological Julian Dates (CJD) . Entonces, en la configuración de datasets.xml para un conjunto de datos SeaDataNet en ERDDAP, en la sección <addAttributes> para todas las variables de tiempo, debe agregar
<att name="units">days since -4712-01-01T00:00:00Z</att>
de modo que 4713 a. C. se expresa como el año astronómico número -4712. Como comprobación, tenga en cuenta que el inicio del día cronológico juliano número 2.452.952 (o 2452952 "days since -4712-01-01") es 2003-11-08T00:00:00Z.
UTC : en la medida de lo posible, ERDDAP, al igual que la hora Unix y UDUNITS, utiliza la hora universal coordinada (UTC). sistema de tiempo. UTC es la versión moderna del sistema horario GMT. UTC utiliza ocasionalmente segundos intercalares para mantenerse cerca del Tiempo Atómico Internacional (TAI). Los dispositivos GPS utilizan la hora GPS (que no utiliza segundos intercalares) internamente, pero muestran la hora UTC a los usuarios. (Ver https://www.cnmoc.usff.navy.mil/Our-Commands/United-States-Naval-Observatory/Precise-Time-Department/The-USNO-Master-Clock/Definitions-of-Systems-of- Tiempo/ u otras discusiones sobre sistemas de tiempo.) Estrictamente hablando, UTC no se puede utilizar en algunas situaciones para tiempos futuros lejanos (por ejemplo, en modelos), ya que no se puede predecir la aparición de segundos intercalares.
Segundos intercalares : al igual que la hora Unix y UDUNITS, "seconds since 1970-01-01T00:00:00Z" de ERDDAP son una codificación numérica (que no usa segundos intercalares) de la hora UTC (que sí usa segundos intercalares). Al convertir tiempos de cadena a/desde tiempos numéricos, ERDDAP, como el tiempo Unix y UDUNITS, ignora los segundos intercalares. Sin embargo, los tiempos numéricos ERDDAP, Unix y UDUNITS dicen que usan UTC. He aquí por qué y cómo: dado que los relojes de las computadoras no son buenos cronometradores, se desvían de la hora UTC y ocasionalmente deben restablecerse a la hora UTC. El tiempo Unix trata los segundos intercalares como parte de la desviación de tiempo causada por la desviación del reloj. Esto permite que el software codifique y calcule el tiempo e ignore los segundos intercalares. Con los valores de tiempo numéricos ERDDAP, hora Unix y UDUNITS, todos los minutos se tratan como si tuvieran 60 segundos, aunque los minutos UTC con segundos intercalares tienen 61 segundos. Tenga en cuenta que los programas de bases de datos como Oracle , MySQL (y probablemente también MariaDB), PostgreSQL y lenguajes como C# Básicamente, también intenta ignorar los segundos intercalares. Esto no causará problemas al convertir valores de fecha+hora+zona horaria de cadena UTC en valores numéricos ERDDAP si luego las horas se reconvierten nuevamente a cadena Zulu de fecha+hora+ de una manera que también ignore los segundos intercalares. Los dos errores se anularán mutuamente. Una consecuencia desafortunada es que ERDDAP, el tiempo Unix y los tiempos numéricos UDUNITS no tienen ningún mecanismo para codificar los segundos intercalares reales como números de manera inequívoca. Por ejemplo, tanto el segundo intercalar 2008-12-31T23:59:60Z como el segundo siguiente 2009-01-01T00:00:00Z están codificados como 1230768000 seconds since 1970-01-01T00:00:00Z . Esto es un defecto, pero sólo afecta a los segundos intercalares reales. De manera similar, si necesita calcular el número exacto de segundos UTC entre dos puntos en el tiempo, puede usar ERDDAP para manejar los datos de tiempo, pero restar un valor de tiempo numérico del otro es solo el primer paso en el cálculo. Debe ajustar manualmente ese valor consultando una tabla de segundos intercalares .
Tiempos y lapsos de tiempo de baja resolución (rangos de tiempo) : si los datos de tiempo se registraron en una resolución más baja (p. ej., un minuto, hora, día, mes o año) o representan un lapso de tiempo (p. ej., una hora, día, 7 -período de días, mes, año), ERDDAP requiere que se utilice un punto de tiempo (lo llamamos "tiempo nominal") para representar ese tiempo o lapso de tiempo. El uso de un tiempo nominal permite que los puntos de tiempo, los puntos de tiempo de baja resolución y los intervalos de tiempo sean interoperables. (Imagínese visualizar diferentes conjuntos de datos en un programa como Google Earth y usar un control deslizante de tiempo para controlar qué subconjunto de datos es visible). Los puntos de tiempo seleccionados más comúnmente para el tiempo nominal son el tiempo de inicio y el tiempo centrado (menos común, pero tiene ventajas para el uso con controles deslizantes de tiempo). Le recomendamos que utilice los metadatos long_name para identificar esto (por ejemplo, "Hora de inicio" o "Hora centrada"). Para tiempos de baja resolución, considere, por ejemplo, "Fecha", "Mes" y "Año". Y/o coloque los detalles en los metadatos "comment" de la variable.
O, para representar con mayor precisión los períodos de tiempo, puede configurar un conjunto de datos para que tenga una variable beginTime y endTime (e incluso una centeredTime, si desea cubrir todas las posibilidades).
Estas son respuestas imperfectas. La configuración actual intenta poner orden en el caos del formato de tiempo, aborda razonablemente bien la mayoría de las situaciones y coincide con las expectativas de la mayoría de las personas sobre cómo funciona el tiempo (incluso si no han pensado en ello en detalle), pero no en todas. Pero así es como funciona ERDDAP actualmente.

¿Quiere realizar conversiones de tiempo desde un programa informático, un script o una página web?

Si cambia la extensión de la URL de esta página web de .html a .txt, ERDDAP responderá solo con el resultado del texto.

Un ejemplo que convierte una hora de cadena en una hora numérica es:
https://coastwatch.pfeg.noaa.gov/erddap/es/convert/time.txt?stringTime=1985-01-02T00:00:00Z&units=segundos%20since%201970-01-01T00:00:00Z
O puede utilizar algún otro formato, por ejemplo,
https://coastwatch.pfeg.noaa.gov/erddap/es/convert/time.txt?stringTime=Jan%202,%201985&units=segundos%20since%20Jan%201,%201970
Un ejemplo que convierte una hora numérica en una hora de cadena es:
https://coastwatch.pfeg.noaa.gov/erddap/es/convert/time.txt?n=473472000&units=segundos%20since%201970-01-01T00:00:00Z
El formato recomendado para el tiempo base en unidades es el formato ISO 8601, pero puede especificar el tiempo base en cualquier formato común, por ejemplo,
https://coastwatch.pfeg.noaa.gov/erddap/es/convert/time.txt?n=473472000&units=segundos%20since%201/1/1970
Tenga en cuenta que el formato de "barra diagonal" se interpreta a la manera estadounidense (como mes/fecha/año), no a la manera europea (como fecha/mes/año).
En algunas versiones anteriores de ERDDAP, el convertidor de cadena a numérico requería una cadena con formato ISO 8601 y usaba el nombre del parámetro isoTime. Todavía puedes usar eso, por ejemplo,
https://coastwatch.pfeg.noaa.gov/erddap/es/convert/time.txt?isoTime=1985-01-02T00:00:00Z&units=segundos%20since%201970-01-01T00:00:00Z
Si especifica isoTime, el parámetro "&units=..." es opcional. El valor predeterminado es "seconds since 1970-01-01T00:00:00Z" .
Un ejemplo que convierte cualquier tiempo de cadena común en un tiempo de cadena ISO 8601 es:
https://coastwatch.pfeg.noaa.gov/erddap/es/convert/time.txt?stringTime=1/2/1985
Debe especificar una parte de la fecha. La porción de tiempo es opcional. Si solo especifica una fecha, el convertidor devolverá que el valor será solo una fecha. Si especifica una parte de fecha y una parte de hora, el convertidor devolverá una fecha y una hora.
Tenga en cuenta que el formato de "barra diagonal" se interpreta a la manera estadounidense (como mes/fecha/año), no a la manera europea (como fecha/mes/año).
Un ejemplo que convierte una cadena de unidades en una cadena de unidades con una hora de cadena ISO es:
https://coastwatch.pfeg.noaa.gov/erddap/es/convert/time.txt?units=SEC%20SINCE%20Jan%202%2C%201985

Codificación porcentual: los valores de los parámetros en la URL (las partes después de los signos '=' ) deben estar codificados porcentualmente correctamente. : todos los caracteres distintos de A-Za-z0-9_-!.~'()* deben codificarse como %HH, donde HH es el valor hexadecimal de 2 dígitos del carácter; por ejemplo, un espacio se convierte en %20. Los caracteres superiores al #127 deben convertirse a bytes UTF-8, luego cada byte UTF-8 debe estar codificado en porcentaje (solicite ayuda a un programador). Hay sitios web que codifican y decodifican por ciento para usted. (external link) .