Horas que se saltan, horas que se repiten y cómo gestionan las zonas horarias los programadores de redes sociales

¿Cómo gestionan las zonas horarias los programadores de redes sociales?

Por dentro, cómo gestionan las zonas horarias los programadores de redes sociales se reduce a una regla: guardar la hora de reloj que eligió la persona junto con el nombre de zona IANA en el que la eligió, y convertir ese par en un instante UTC solo cuando una API de plataforma necesita una marca de tiempo. "Las 9:00 en America/New_York el 15 de julio" es la intención. 2026-07-15T13:00:00Z es lo que recibe la API.

El nombre de zona importa porque lleva consigo las reglas. La IANA Time Zone Database, que según IANA contiene "the history of local time for many representative locations worldwide", está "updated periodically to reflect changes made by political bodies to time zone boundaries, UTC offsets, and daylight-saving rules." La versión publicada en iana.org cuando se escribió esta página era 2026d. Un nombre como Europe/Berlin apunta a esas reglas. Un offset como +01:00 no apunta a nada y se queda desfasado dos veces al año.

Todas las demás decisiones de diseño se derivan de esa separación entre intención e instante. El resto de esta página cubre dónde se rompe cada mitad.

¿Por qué un offset UTC fijo es lo que no hay que guardar?

Un offset fijo registra lo que marcaba el reloj un día concreto y da por hecho que se mantiene para siempre. Guarda las 9:00 de Nueva York en enero como 09:00-05:00, reutiliza ese offset para un post de julio y el post cae en 2026-07-15T10:00:00-04:00. Eso son las 10:00 locales, una hora tarde, porque Nueva York funciona en UTC-4 en verano.

El RFC 9557, el documento del IETF que añade nombres de zona entre corchetes a las marcas de tiempo del RFC 3339, advierte justo contra esto. Califica los offset time zones de "strongly discouraged" y dice que los programas "MUST NOT copy the UTC offset from a timestamp into an offset time zone." Su propio ejemplo muestra por qué: 2020-01-01T00:00+01:00[Europe/Paris] permite a un programa sumar seis meses y caer en la hora de verano correcta, mientras que el mismo cálculo sobre 2020-01-01T00:00+01:00[+01:00] "will produce an incorrect result that will be off by one hour in the time zone Europe/Paris."

El mismo fallo se esconde en los posts recurrentes. Un hueco semanal guardado como "cada lunes a las 08:00 UTC" se desplaza una hora para todo el que esté fuera de UTC cuando cambian sus relojes. Un hueco guardado como "cada lunes a las 08:00 Europe/London" no se mueve.

¿Qué le pasa a un post programado en la hora que se salta?

Apunta a una hora que nunca existe, y el programador tiene que elegir una real. En 2026, Nueva York adelanta sus relojes de las 02:00 a las 03:00 el 8 de marzo, a las 07:00Z. Nada entre las 02:00 y las 02:59 ocurre ese día. Un post reservado para las 02:30 no tiene ningún instante que le corresponda.

La API Temporal de JavaScript hace explícita la elección con su opción disambiguation, que admite "compatible", "earlier", "later" o "reject". MDN documenta el valor por defecto así: "compatible (default): Same behavior as Date: use later for gaps and earlier for ambiguities." Con "compatible", las 02:30 pasan a ser las 03:30 EDT, que es 07:30Z. El zoneinfo de Python da el mismo instante con fold=0 y 06:30Z, una hora antes, con fold=1.

"reject" es la opción honesta para una interfaz de programación. Rechaza el hueco y dile a la persona que las 02:30 no existen esa noche, en lugar de mover su post sin avisar. Para un proceso en segundo plano que tiene que dispararse pase lo que pase, "compatible" es la regla menos sorprendente, y coincide con lo que ya hace Date.

¿Qué pasa en la hora que se repite?

La misma hora de reloj ocurre dos veces, y el programador tiene que elegir una. El 1 de noviembre de 2026, Nueva York retrasa la hora de las 02:00 EDT a la 01:00 EST a las 06:00Z, así que la 01:30 ocurre una vez a las 05:30Z y otra a las 06:30Z. Las marcas de tiempo UNIX son 1793511000 y 1793514600, separadas exactamente por 3,600 segundos.

La regla de MDN para "compatible" es "earlier for ambiguities", así que un programador basado en Temporal publica en la primera 01:30. El zoneinfo de Python hace lo mismo con fold=0. En cualquier caso la regla tiene que vivir en el código, porque nada en "01:30 America/New_York" dice cuál de los dos instantes quería la persona. Un calendario que muestre las dos opciones esa única noche evita tener que adivinar.

¿Por qué importan los desfases entre EE. UU. y Europa al publicar a nivel global?

Las dos regiones cambian la hora en fechas distintas, así que la diferencia entre ellas no es constante. En 2026, Londres y Berlín adelantan la hora el 29 de marzo a las 01:00Z, tres semanas después que Nueva York. Del 8 al 29 de marzo, Nueva York va cuatro horas por detrás de Londres en lugar de cinco. En otoño, Europa retrasa la hora el 25 de octubre y Nueva York el 1 de noviembre, lo que abre otra semana con cuatro horas de diferencia.

Estas fechas salen de la base de datos tz, no de una regla aproximada. Un programador que tenga fijado en el código "Londres es Nueva York más cinco" publica con una hora de desfase cuatro semanas al año. Uno que convierte cada post a través de su propio nombre de zona acierta en las cuatro semanas sin casos especiales. Esto importa sobre todo cuando una misma campaña sale en varias regiones, cada una a su mejor hora para publicar en redes sociales local.

¿Qué formatos de hora aceptan las APIs de las plataformas?

Todas las APIs de plataforma que admiten una hora futura quieren un instante absoluto: un entero UNIX o una cadena ISO 8601 o RFC 3339 con offset o con Z. Ninguna admite un nombre de zona IANA. La tabla recoge los campos de programación que describe la documentación de cada plataforma.

Dos detalles de esa tabla pillan a la gente. La guía de la Pages API de Meta escribe el estándar como "ISO 8061", una errata por ISO 8601 en la misma página que define el campo. Y los Reels de Facebook solo aceptan la forma entera, así que un programador que envía cadenas ISO a /feed necesita un camino de código aparte para los Reels.

Bluesky es un caso especial. No tiene campo de programación, pero todo registro de post lleva un createdAt obligatorio, que el lexicon describe como "Client-declared timestamp". La especificación de atproto dice "Timezone specification is required" y "It is strongly preferred to use the UTC timezone, and to represent the timezone with a simple capital Z suffix." Un post de Bluesky en cola debería recibir su createdAt en el momento del envío, no cuando se redactó.

¿Alguna API de plataforma acepta un nombre de zona horaria?

No. Ninguna de las documentaciones de programación de plataformas que se cubren aquí acepta una cadena como America/New_York. La conversión de nombre de zona a instante siempre es trabajo del programador, y la plataforma nunca ve la zona.

Facebook es la que más se acerca a hacer la conversión por su cuenta, y esa es la parte arriesgada. La guía de Meta acepta cadenas relativas de strtotime() como +2 weeks y tomorrow, pero no dice en qué zona se resuelve "tomorrow". El consejo de la propia Meta es que "If you are relying on strtotime()'s relative date strings you can read-after-write the scheduled_publish_time of the created post to make sure it is what is expected." Un programador que envía una marca de tiempo UNIX ya calculada nunca necesita esa comprobación.

El RFC 9557 sí define un sitio para un nombre de zona, como sufijo entre corchetes: 2022-07-08T00:14:07+01:00[Europe/Paris]. Ninguno de los endpoints de programación anteriores documenta soporte para ese sufijo, así que quítalo antes de enviar. El detalle por plataforma de dos de estos campos está en las reglas de antelación de scheduled_at en Mastodon y en cada campo publishAt de YouTube y sus modos de fallo.

¿Qué debe guardar un programador para cada post?

Tres cosas: la hora de reloj local, el nombre de zona IANA y el instante UTC derivado de ellos. Los dos primeros son la fuente de verdad. El tercero es una caché para que la cola ordene y dispare.

El motivo para guardar la hora local es que las reglas de zona cambian después de programar. MDN lo dice claramente: "if you store a time in the future, with an anticipated offset, then before that time comes, the time zone definition may have changed due to political reasons." Cuando sale una actualización de la base de datos tz, recalcula el instante UTC de cada post futuro a partir de su hora de reloj y su zona. Un sistema que solo guardó UTC no puede hacerlo, porque ya no sabe qué pidió la persona.

La otra mitad es el camino de envío. Convierte al formato que quiere cada API en el momento del envío: un entero para los Reels de Facebook, ISO con sufijo Z para YouTube y Mastodon, minutos enteros para X Ads. Comprueba el resultado contra la antelación mínima de la plataforma antes de enviar. Mastodon rechaza cualquier cosa a menos de 5 minutos, y Facebook cualquier cosa a menos de 10. Acertar con esas comprobaciones es la mayor parte de lo que separa una cola fiable de una que programa publicaciones en redes sociales a la hora equivocada dos veces al año.

Preguntas frecuentes

¿Debe un programador de redes sociales guardar las horas en UTC?

Guarda el instante UTC para ordenar y disparar, pero no como único registro. Guarda también la hora de reloj y el nombre de zona IANA, para poder recalcular el instante cuando la base de datos tz cambie las reglas de una zona. MDN señala que la definición de una zona "may have changed due to political reasons" antes de que llegue una hora futura.

¿Qué es un nombre de zona horaria IANA?

Es un identificador de la IANA Time Zone Database, como America/New_York, Europe/London o Asia/Tokyo. Cada nombre apunta al historial completo de offsets UTC y reglas de horario de verano de ese lugar. IANA describe la base de datos como "updated periodically to reflect changes made by political bodies".

¿Qué pasa si programo un post a las 2:30 de la madrugada la noche en que se adelanta la hora?

En Nueva York, el 8 de marzo de 2026, las 02:30 no existen. Con la regla por defecto "compatible" de Temporal, el post se mueve a las 03:30 EDT, 07:30Z. Con "reject", el programador lanza en cambio un RangeError, lo que permite a la interfaz pedir a la persona que elija otra hora.

¿El scheduled_publish_time de Facebook acepta una zona horaria?

Solo como offset dentro de una cadena ISO 8601, como 2018-09-01T10:15:30+01:00, que es el propio ejemplo de Meta. También acepta una marca de tiempo UNIX en segundos y cadenas de strtotime(). La guía de Meta no dice en qué zona se resuelven las cadenas relativas como tomorrow, y recomienda leer el valor de vuelta para comprobarlo.

¿Qué formato quiere la API de YouTube para publishAt?

El recurso videos de Google dice que status.publishAt "is specified in ISO 8601 format." Envía una fecha y hora completas con Z o con un offset explícito. Google documenta que un valor pasado publica el vídeo "right away", así que un fallo de conversión que empuje la hora al pasado hace que el vídeo salga al momento en lugar de devolver un error.

¿Por qué mis posts programados van una hora desfasados cuando termina el horario de verano?

La causa habitual es un offset fijo guardado. Un post guardado como 09:00-04:00 en verano sigue disparándose a las 13:00 UTC después del cambio de hora, que en invierno son las 08:00 en Nueva York. Guardar America/New_York con la hora de reloj y recalcular el instante lo arregla.

¿Qué pasa con un post programado a la 1:30 cuando se atrasan los relojes?

El 1 de noviembre de 2026 Nueva York repite de 01:00 a 01:59, así que la 01:30 ocurre a las 05:30Z y otra vez a las 06:30Z. Con la regla por defecto "compatible" de Temporal, y con zoneinfo de Python con fold=0, el post sale en la primera. La regla tiene que vivir en el código del programador, porque "01:30 America/New_York" no dice cuál de los dos instantes quiso decir la persona.

¿Por qué Nueva York va solo cuatro horas por detrás de Londres algunas semanas?

EE. UU. y Europa cambian los relojes en fechas distintas. En 2026 Nueva York adelanta la hora el 8 de marzo y Londres el 29 de marzo, y entre ambas fechas Nueva York va cuatro horas por detrás de Londres en vez de cinco. En otoño se abre otra semana de cuatro horas, desde el 25 de octubre, cuando Europa atrasa la hora, hasta el 1 de noviembre, cuando lo hace Nueva York.

¿Se puede programar un post con la API de Instagram o LinkedIn?

En la documentación que cubre este artículo, los endpoints de creación de Instagram, Threads, LinkedIn, TikTok, Pinterest y X API v2 no tienen campo de hora futura. Facebook, YouTube, Mastodon y X Ads sí lo tienen. Para el primer grupo, el programador debe guardar el post y enviarlo cuando llegue la hora.

¿Qué marca de tiempo debe llevar un post de Bluesky?

Bluesky no tiene campo de programación, pero cada registro de post exige un createdAt, que el lexicon describe como "Client-declared timestamp". La especificación de atproto exige indicar la zona horaria y prefiere UTC con una Z mayúscula como sufijo. Un post en cola debe recibir su createdAt al enviarse, no cuando se redactó.