Cuenta Atrás hasta la Fecha — Días/Horas hasta Cumpleaños, Festivo o Deadline
Elige una fecha y hora objetivo y la página muestra una cuenta atrás en vivo — días, horas, minutos, segundos — que descuenta un segundo cada vez. Útil para seguir los días hasta un cumpleaños, festivo, fecha límite de un proyecto, fin de contrato, evento deportivo, nacimiento de hijo, fecha de jubilación o cualquier hito del que quieras un recordatorio constante. La cuenta atrás también muestra el desglose total (p. ej. "137 días = 3.288 horas = 197.280 minutos") que es útil para planificación de proyectos, comparar plazos o pensar en una fecha límite en distintas escalas temporales.
Sobre esta herramienta
Cada tick recalcula `target - Date.now()` en lugar de incrementar un contador con `setInterval`. Así la cuenta atrás se mantiene precisa incluso cuando el navegador limita las pestañas inactivas (Chrome/Firefox ralentizan timers de pestañas en background a 1 Hz o menos para ahorrar batería, lo que haría que un contador basado en `setInterval(fn, 1000)` derivara). El compromiso es que los cambios del reloj local (corrección NTP, transición de horario de verano, ediciones manuales del reloj) desplazan al instante la cuenta atrás visible. En la mayoría de los casos, ese es el comportamiento correcto. El objetivo se trata como hora wall-clock en la zona horaria local de tu navegador; la página gestiona fechas pasadas mostrando "El evento ha pasado" en vez de números negativos. Acepta cualquier formato de campo datetime-local HTML5. Usos habituales: cuenta atrás de Nochevieja en una televisión de fondo, recordatorios de festivos, fecha límite de proyecto, seguimiento de aniversarios, ritmo de estudio para un examen, cuenta atrás de viaje a conferencia, jubilación/sabático, seguimiento de fecha de parto, fechas de torneo deportivo.
- Cuenta atrás en vivo que descuenta un segundo cada vez hasta tu objetivo del reloj local
- Días, horas, minutos, segundos — más desgloses totales
- Recálculo Date.now() en cada tick — sobrevive throttling de pestaña
- Gestiona objetivo pasado de forma controlada ("El evento ha pasado")
- Trata el objetivo como hora local wall-clock (maneja transiciones DST)
- Funciona como pantalla fija o televisión de fondo si la dejas en una pestaña
- Sin subida — sin registro de qué estás contando hacia atrás
- Se pausa cuando la pestaña queda oculta gracias al ahorro energético estándar del navegador (se reanuda al volver al primer plano)
- Input datetime-local HTML5 — funciona también en táctil
- Útil para cumpleaños, festivos, fechas límite, exámenes, bodas, conferencias
Gratis. Sin registro. Tus datos permanecen en tu navegador. Anuncios mediante Google AdSense (con consentimiento).
Preguntas frecuentes
¿Cómo sobrevive una cuenta atrás basada en Date.now() al throttling de pestañas del navegador?
La limitación de pestañas de Chromium (Chrome 87 estable, 17 de noviembre de 2020) ralentiza las llamadas (callbacks) de `setInterval` y `setTimeout` en pestañas de fondo a un mínimo de 1 Hz para ahorrar batería en portátiles y móviles; Chrome 88 (enero de 2021) añade limitación intensiva que reduce los disparos a una vez por minuto para pestañas ocultas más de 5 minutos. Una cuenta atrás que incrementa un contador vía `setInterval(fn, 1000)` derivará detrás del tiempo real cuando su pestaña esté en fondo — el contador dice "5 horas restantes" cuando el reloj de pared dice 4 horas restantes. El patrón de recálculo — `target − Date.now()` en cada tick — evita la deriva por completo. Cada tick visible lee la hora actual al momento, así que la cuenta atrás mostrada refleja el tiempo restante real sin importar con qué frecuencia se ejecute el tick. Como contrapartida, cuando la pestaña está en segundo plano, la cuenta atrás se congela visualmente hasta que vuelve a primer plano, luego salta al valor correcto. Combinado con la W3C Page Visibility API (Recomendación 2013), la página puede re-renderizar inmediatamente en el evento visibilitychange cuando la pestaña vuelve al primer plano.
¿Qué es el problema Y2038 y cuándo importa?
El problema Y2038 es el desbordamiento del timestamp Unix: POSIX time_t (según IEEE Std 1003.1) es tradicionalmente un entero con signo de 32 bits que cuenta segundos desde el epoch Unix 1970-01-01T00:00:00Z. El entero con signo máximo de 32 bits 2³¹ − 1 = 2.147.483.647 corresponde a las 03:14:07 UTC del martes 19 de enero de 2038 — pasado ese momento, el contador desborda a valores negativos, rompiendo la aritmética de fechas y haciendo que cualquier cuenta atrás a una fecha posterior a 2038 sea silenciosamente errónea. Los sistemas modernos han pasado a time_t de 64 bits: kernel Linux 5.6 (marzo 2020), macOS 10.7 Lion (2011), Windows NT internamente desde hace décadas. Los sistemas embebidos (control industrial, coches, electrodomésticos), las bases de datos antiguas y los binarios de 32 bits sobre sistemas operativos de 64 bits siguen siendo vulnerables. El objeto Date de JavaScript usa ms-desde-epoch de doble precisión IEEE-754 (rango ±100.000.000 días desde 1970), así que las cuentas atrás de navegador no se ven afectadas hasta el año 275760 — pero si el objetivo de la cuenta atrás se procesa por un servidor, formato de fichero o dispositivo con time_t de 32 bits, el desbordamiento se vuelve visible.
¿Cómo afectan las transiciones de horario de verano a una cuenta atrás?
Una cuenta atrás usando hora local del reloj de pared puede mostrar discontinuidad visible de ±1 hora en un límite DST. La primavera UE (último domingo de marzo, +1 hora: los relojes saltan 02:00 → 03:00 en CET, equivalentemente 01:00 UTC según la Directiva 2000/84/CE) hace que una cuenta atrás dirigida a una fecha pasado el límite pierda 1 hora en ese momento — las "5 horas 30 minutos" visibles pasan a ser "4 horas 30 minutos". El cambio de hora de octubre en la UE (último domingo, −1 hora: los relojes repiten 03:00 → 02:00 en CET) hace lo inverso — la cuenta atrás gana 1 hora. El DST de EE.UU. va en domingos distintos (segundo domingo de marzo, primer domingo de noviembre) según la Energy Policy Act de 2005. Una cuenta atrás usando UTC esquiva esto por completo (UTC no tiene DST) pero pierde el lectura natural en hora local — "3 horas hasta medianoche" se lee natural solo en hora local. La página trata el objetivo como hora local de reloj de pared, así que las discontinuidades de límite DST son visibles por diseño.
¿Qué precisión tiene una cuenta atrás de pestaña de navegador vs hora de servidor?
Los relojes del navegador dependen del reloj del sistema operativo, que se sincroniza al tiempo de internet vía NTP (Network Time Protocol, RFC 5905, deriva típica de unas decenas de milisegundos cuando hay conexión de red). La precisión de la cuenta atrás está por tanto acotada por la precisión del reloj del SO más la granularidad del tick del event loop de JavaScript (normalmente 4-16 ms vía requestAnimationFrame, o 1000 ms limitado en pestañas de fondo según la política Chromium arriba). Para cuentas atrás prácticas (plazos, festivos, eventos), esto es más que suficientemente preciso — unos pocos milisegundos de deriva por minuto son invisibles. Para precisión sub-segundo (p. ej. cuenta atrás de Nochevieja a un reloj de servidor específico), la página tendría que recoger la hora del servidor periódicamente y ajustar — lo que la mayoría de UIs de cuenta atrás no se ocupan de hacer porque el NTP del SO mantiene los relojes dentro de unos cientos de milisegundos de la hora real globalmente.
¿Qué es la Page Visibility API y cómo se relaciona?
La W3C Page Visibility API (Recomendación 29 de octubre de 2013) expone si una pestaña está actualmente visible al usuario vía `document.hidden` (booleano) y el evento `visibilitychange`. Es el mecanismo estándar que los navegadores usan para informar a las páginas sobre el estado de foco de pestaña, separado de los eventos más antiguos `window.focus`/`blur` (que se disparan solo para foco de pestaña+ventana, no cambio de pestaña dentro de una ventana). Combinado con el patrón de recálculo Date.now(), una cuenta atrás puede: (a) saltar fotogramas de animación mientras está oculta para ahorrar CPU, (b) saltar directamente al valor correcto cuando la pestaña vuelve al primer plano (vía el evento visibilitychange disparándose con `document.hidden = false`). Los navegadores modernos limitan setInterval a un mínimo de 1 Hz en pestañas ocultas (limitación de pestañas de Chromium, Chrome 87 estable, 17 de noviembre de 2020) de todos modos, así que la Page Visibility API ayuda principalmente con la re-sincronización al volver a primer plano en vez de reducir la limitación.
Fuentes (7)
- International Organization for Standardization (2019). ISO 8601-1:2019 — Date and time format YYYY-MM-DDTHH:MM:SS underlying the HTML datetime-local input value, the Date.now() millisecond timestamp display, and any human-readable countdown target rendering; locale-unambiguous + lex-sortable. ISO Technical Committee 154 (TC 154); supersedes ISO 8601:2004.
- WHATWG (Web Hypertext Application Technology Working Group) (2024). HTML Living Standard — input element type=datetime-local; YYYY-MM-DDTHH:MM:SS format (ISO 8601 profile without time zone offset); browser-native date+time picker on mobile and desktop; widely supported across Chromium / Firefox / WebKit since 2017. WHATWG HTML Living Standard (continuously updated; this section stable since HTML5 2014); accessible at html.spec.whatwg.org.
- Mills, D., Martin, J., Burbank, J., & Kasch, W. (2010). RFC 5905 — Network Time Protocol Version 4 (NTPv4): Protocol and Algorithms Specification. Defines the algorithm OS clocks use to synchronise to internet time servers; typical drift bounded to a few tens of milliseconds when network-connected, which sets the floor on browser countdown accuracy via the OS clock. Internet Engineering Task Force (IETF) Proposed Standard, June 2010; supersedes RFC 1305 NTPv3.
- Ecma International (2024). ECMA-262, 15th edition (June 2024) — ECMAScript Language Specification §21.4 Date Objects; Date.now() returns ms since Unix epoch 1970-01-01 UTC as IEEE-754 double; the recompute pattern target − Date.now() per tick stays accurate even when setInterval timers are throttled by browser background-tab energy-saving. Ecma International TC39; current standard ECMA-262 published annually since ES5 (2011).
- IEEE / The Open Group (2018). POSIX.1-2017 (IEEE Std 1003.1-2017) — defines time_t as seconds since the Unix epoch 1970-01-01T00:00:00Z UTC. The Y2038 problem: signed 32-bit time_t wraps at 03:14:07 UTC on Tuesday 19 January 2038 (when seconds-since-epoch exceeds 2³¹ − 1 = 2,147,483,647). Linux 64-bit time_t since kernel 5.6 (March 2020) avoids this; macOS 64-bit since 10.7 Lion (2011); embedded + legacy 32-bit systems remain vulnerable. Institute of Electrical and Electronics Engineers / The Open Group joint standard (current revision IEEE Std 1003.1-2024).
- World Wide Web Consortium (W3C) / Chromium Project (2013). Page Visibility API (Second Edition) — visibilitychange event fires when a tab moves to background or returns to foreground; document.hidden boolean indicates current state. Combined with Date.now() recompute on each tick, a countdown re-syncs immediately on tab refocus. Chromium tab throttling (Chrome 87 stable, 17 November 2020) caps background setInterval frequency to 1 Hz; Chrome 88 (January 2021) intensive throttling further reduces wake-ups to once per minute for tabs hidden > 5 minutes. W3C Page Visibility API Recommendation (Second Edition) 29 October 2013; Chromium tab throttling documented at blog.chromium.org/2020/11/tab-throttling-and-more-performance.html and intensive throttling at developer.chrome.com/blog/timer-throttling-in-chrome-88.
- World Wide Web Consortium (W3C) (2018). Web Content Accessibility Guidelines (WCAG) 2.1 — Success Criterion 4.1.3 Status Messages. W3C Recommendation 5 June 2018; carried unchanged into WCAG 2.2 (Recommendation 5 October 2023).
Son las publicaciones originales en las que se basan las fórmulas de esta herramienta. Localízalas con el nombre de la revista y el año en Google Scholar o PubMed.
Por Marco B. ·