Lección 5
Errores frecuentes con timestamps
Y2038, segundos flotantes, unidades incorrectas y cadenas de fecha ambiguas.
Aunque los formatos parezcan simples, los timestamps fallan de formas predecibles. Reconocer el patrón ahorra horas de depuración.
Y2038 y límites de enteros
El clásico time_t con signo de 32 bits desborda alrededor del 2038-01-19. Sistemas embebidos heredados y binarios antiguos pueden seguir usando segundos de 32 bits. Los servidores modernos de 64 bits evitan esto en almacenamiento, pero CSV exportados y clientes antiguos quizá no.
JavaScript Date usa doubles de milisegundos — el rango seguro es enorme, pero enteros muy grandes pegados en parsers pueden seguir fallando.
Error por factor 1000 (segundos vs milisegundos)
Síntomas:
- Fecha cerca de 1970-01-01 → trataste segundos como milisegundos (valor demasiado pequeño)
- Fecha en el año 50000+ → trataste milisegundos como segundos
Pregunta siempre: «¿Este campo está documentado como sec o ms?»
Cadenas locales ambiguas
2024-06-01 00:30 sin zona horaria significa instantes distintos en Tokio vs Toronto. Parsearlo como «local del servidor» vs «local del usuario» vs «UTC» cambia drásticamente los informes de errores.
Huecos y repeticiones por horario de verano
En días de transición DST, las horas locales de pared pueden repetirse u omitirse. Programar «2:30 AM local» el día de retroceso puede ser inválido o ambiguo. Almacena instantes UTC para alarmas y facturación.
Sorpresas de locale en cadenas
03/04/2024 es 4 de marzo en locale US pero 3 de abril en locale EU. Prefiere ISO 2024-03-04 en campos legibles por máquina.
Conclusión clave
La mayoría de errores de timestamp son confusión de unidades, zona horaria ausente o límites de ancho heredados — no matemática exótica. Comprueba esos tres primero. El Conversor de timestamp UTC ayuda a detectar unidades equivocadas al instante.