Hace unos días me volvió a pasar. Quedé con un cliente para hacer una migración de un WooCommerce gordo (el tipo de migración que no puedes hacer en horario comercial porque cada minuto de tienda caída es un minuto de alguien sin cobrar) y me dijo: «Nos conectamos a primera hora».
Yo, criado en la tradición de que «primera hora» en infraestructura significa «antes de que el mundo despierte», me levanté a las 4:45, me preparé una bebida calentita, me conecté a la VPN y esperé. A las 5:15 ya tenía todo preparado. A las 7:43 me llega un mensaje: «Buenos días, ya estoy, ¿empezamos?».
En ese momento, mientras miraba mi tercer desayuno y la pantalla que llevaba dos horas y media encendida, me di cuenta de algo evidente: «a primera hora» es peor que un cron mal escrito. Al menos un cron mal escrito falla de forma reproducible.
Una «variable» sin definir
Como sysadmin, mi cerebro tiene una regla grabada a fuego: si algo no tiene formato ISO 8601, no es una hora (sí, no será la primera vez que alguien me pregunta porqué siempre pongo la fecha en plan 2026-07-30). Y sin embargo, sigo cayendo en la trampa de las frases hechas.
«A primera hora» suena inofensivo, pero es una ambigüedad crítica. Es lo que en ingeniería llamaríamos un timestamp relativo sin referencia de contexto. Y es peligroso.
Porque «primera hora» depende radicalmente de quién habla:
- Para un desarrollador junior, es cuando abre el portátil, tras el café y revisar Slack.
- Para un desarrollador senior, es las 7:30, antes de que empiecen las daily meetings.
- Para un comercial, es las 9:00 en punto, cuando empieza su calendario.
- Para un cliente alemán, es las 8:00 CET, que para mí son las 7:00 UTC o las 8:00 según haya cambio de hora.
- Para mí, es cuando aún no ha salido el sol y el único tráfico en la B-20 son los que vuelven de fiesta.
Y ahí está el fallo: usamos una expresión heredada de un sistema horario que ya no existe, aplicada a un mundo donde cada persona vive en un runtime diferente.
La hora primera romana
En Roma, el día se dividía en doce horas (horae) contadas desde el amanecer. La prima hora era, literalmente, la primera franja de luz. Era una referencia absoluta y solar: cuando el sol rozaba el horizonte, empezaba la cuenta. No había confusión posible porque no había relojes mecánicos, ni zonas horarias, ni un comercial con el calendario de Google mal configurado.
La hora sexta caía al mediodía, y de ahí viene la siesta, esa pausa canónica que para los romanos tenía sentido climático y astronómico, y que hoy es simplemente una excusa para no contestar el teléfono después de comer pasta.
El sistema funcionaba porque era relativo al sol, no relativo a la costumbre de cada uno. Pero cuando los relojes mecánicos impusieron las horas de duración fija en el siglo XIV, mataron la variable solar. Y nosotros, tercos como somos, seguimos usando las palabras sin el rigor que las sustentaba.
Implicaciones: el sysadmin madrugador
En mi caso, el error es predecible: yo interpreto «primera hora» como prima hora en sentido romano y militar. Si hay una migración, un despliegue crítico o una restauración de backup, mi instinto de supervivencia me dice que el único horario seguro es aquel en el que nadie más está despierto para tocar nada. Es la versión sysadmin del maintenance window: si todos duermen, nadie puede romper lo que estoy arreglando.
Pero el cliente no piensa así. Para él, «primera hora» es la primera hora útil de su jornada. Mientras yo estaba en modo prima hora, él estaba en modo duodécima hora del día anterior.
La consecuencia es que he aprendido (a fuego lento, entre bebidas frías y amaneceres en pantalla) que «a primera hora» debe ser tratado como un null pointer. Si no lo desreferencias con una hora exacta, una zona horaria y un canal de confirmación, explota en tu cara a las 7:43 de la mañana.
Una propuesta de estándar
He llegado a la conclusión de que deberíamos adoptar una convención clara en el sector. Propongo que, cuando alguien diga «a primera hora», respondamos con una de estas tres opciones basadas en el sistema romano:
- Prima hora (~06:00): para quienes madrugamos por vocación o por miedo a la concurrencia.
- Hora sexta (~12:00): para quienes confunden «primera hora» con «antes de comer».
- Hora duodécima (~18:00): para quienes, directamente, no han entendido nada y deberían reprogramarse.
Y, por supuesto, siempre en formato UTC. Si el sol se ponía en Roma sin avisar, hoy tenemos date -u para evitar tragedias.
Conclusión
La próxima vez que alguien me diga «lo hacemos a primera hora», mi respuesta será exactamente esta: «Perfecto. ¿Prima hora, hora sexta o duodécima? Y, por cierto, ¿en qué timezone? Porque mi reloj de sol está en Barcelona y mi paciencia está en un huso horario que ya no se usa desde la caída del Imperio».
En infraestructura no hay espacio para la ambigüedad poética. Si no tiene timestamp ISO, no existe. Y si existe, al menos que sea a una hora en la que ya haya amanecido para ambas partes.
Deja una respuesta