Conversor de Unix timestamp

Timestamps en los logs

Un Unix timestamp cuenta el tiempo transcurrido desde las 00:00:00 UTC del 1 de enero de 1970. Los pipelines de logs mezclan cuatro precisiones, y la cantidad de dígitos de un valor actual permite distinguirlas:

El conversor trata los valores de al menos 12 dígitos como milisegundos y los menores como segundos. Divide los microsegundos entre 1.000 y los nanosegundos entre 1.000.000 antes de convertir; leído como milisegundos, el valor de 16 dígitos de arriba caería en el año 56971.

_time de Splunk

En el momento de indexación, Splunk convierte el timestamp de cada evento a tiempo Unix y lo guarda en _time; la interfaz lo muestra en la zona del usuario. Cuando el evento original no trae zona, Splunk la resuelve en este orden: una zona en el texto del evento, un ajuste TZ en props.conf para la fuente, el host o el sourcetype, la zona que envía el forwarder y, por último, la zona del sistema donde corre splunkd.

@timestamp de Elasticsearch

Los campos de fecha se almacenan como milisegundos desde la época (epoch) en UTC. El formato por defecto acepta cadenas ISO 8601 o epoch_millis; los segundos solo se aceptan si se agrega epoch_second al formato del campo. Enviar un valor en segundos a un campo de fecha con el formato por defecto es un error clásico: 1735689600 leído como milisegundos es 1970-01-21T02:08:09.600Z. Usa date_nanos cuando importe la precisión de nanosegundos.

Timestamps fuera del rango esperado

Splunk compara cada timestamp extraído con la hora actual: MAX_DAYS_AGO y MAX_DAYS_HENCE en props.conf limitan qué tan atrás o adelante en el tiempo puede estar una fecha extraída antes de que Splunk la descarte y asigne otro timestamp. Una fuente que escribe años de dos dígitos o que interpreta mal el orden día/mes puede entonces dejar eventos en el día equivocado sin ningún error. Revisa las fuentes nuevas comparando _time con _indextime en una muestra de eventos; un desfase consistente de horas completas apunta a un problema de zona horaria, y una dispersión aleatoria a un problema de parsing.

Errores de zona horaria en la ingesta

Ejemplo ilustrativo Unos servidores de aplicación en UTC−3 escriben 2026-10-08 09:00:00 sin desfase y lo reenvían por un servidor de syslog que corre en UTC. Si el forwarder lo lee allí y no hay TZ configurado, el evento se almacena como las 09:00 UTC, tres horas antes de que ocurriera (12:00 UTC). Una búsqueda de alerta de 15 minutos nunca ve esos eventos en su ventana. Corrígelo en el origen con un desfase explícito, o define TZ para esa fuente.

Fuentes

• Especificar zonas horarias para los timestamps — documentación de Splunk Enterprise, 10.4
• Tipo de campo date — referencia de Elasticsearch
• Tipo de campo date nanoseconds — referencia de Elasticsearch

Última revisión: octubre de 2026