Generador de fechas aleatorias

Formatos de fecha que conviene conocer

El mundo de las fechas es complicado precisamente porque es un dominio compartido entre humanos, máquinas y zonas horarias. Algunos formatos clave:

• ISO 8601: 2026-04-26T14:30:00Z. Estándar internacional, soporta zona horaria, ordenable como string. Es lo que usan APIs serias.
• ISO date: 2026-04-26. Solo fecha, sin hora. Para columnas DATE en SQL.
• RFC 3339: subset de ISO 8601 más estricto. Es lo que usa JSON Schema y muchos lenguajes.
• Unix timestamp: 1745676600. Segundos desde 1970-01-01 UTC. Compacto y monotónico.
• Local string: 26/04/2026 o 04/26/2026. Bueno para mostrar al usuario, pésimo para almacenar.

UTC vs zonas horarias

La regla de oro en aplicaciones modernas: almacená todo en UTC, mostrá en la zona horaria del usuario. Si guardás fechas en hora local, te enfrentás a:

• Conversiones inconsistentes cuando el servidor está en UTC y la base en otra zona.
• Cambios de horario de verano que crean horas duplicadas o inexistentes.
• Imposibilidad de comparar eventos entre usuarios de distintas zonas.

Para tests, este generador produce fechas en UTC por default. Mezclá con timezones distintos para detectar bugs de conversión.

Fechas en tests automatizados

1. No uses new Date() en assertions. Mockeá el reloj con bibliotecas como Sinon, vitest's vi.useFakeTimers(), o jest mock timers.
2. Reproducibilidad. Si un test depende de fechas, fijá una semilla y un "now" simulado. Si no, los tests pasan o fallan según el momento del día.
3. Edge cases temporales. 29 de febrero, cambios de horario, transiciones de año. Generá fechas que toquen esos casos.
4. Rangos relativos. "Hace 7 días" debería calcularse desde el now mockeado, no desde el real.

El problema del año 2038

Los Unix timestamps de 32 bits con signo desbordan el 19 de enero de 2038 a las 03:14:07 UTC. Sistemas que aún usen time_t de 32 bits van a tener bugs ese día. Es el equivalente moderno del Y2K.

Si generás fechas para tests de futuro, considerá incluir fechas posteriores al 2038 para verificar que tu sistema usa 64 bits o representaciones alternativas (ISO 8601, BigInt). La mayoría de lenguajes modernos ya migraron, pero las bases legacy siguen siendo vulnerables.

Casos de uso típicos

• Fechas de creación de cuentas. Distribución plausible: pocos usuarios viejos, muchos recientes. Generá hasta hace 3-5 años.
• Fechas de pedidos. Concentración en horario laboral, picos en ciertos días. Combinable con la opción "horario laboral".
• Fechas de nacimiento. Rango entre hace 80 y hace 18 años para tests de validación de edad.
• Logs. Distribución uniforme con segundos exactos.
• Vencimientos. Fechas futuras con duraciones plausibles (1-12 meses).

Bugs de fechas que aparecen tarde

Tres bugs clásicos que aparecen recién en producción:

1. Off-by-one en zonas horarias. Un usuario en GMT+10 ve "lunes" cuando tu base lo guarda como "domingo UTC".
2. Truncamiento al insertar. Tu API recibe ISO 8601 con milisegundos pero la columna es TIMESTAMP(0). Pierdes precisión.
3. Format strings hardcodeados. "DD/MM/YYYY" en moment.js falla con datos en formato US.