Calculadora Días entre Fechas — Diferencia en Días, Semanas y Meses
Elige una fecha de inicio y una de fin y la página te dice exactamente cuántos días las separan, con semántica conmutable inclusiva (fecha final contada) vs exclusiva (fecha final no contada) — la elección que importa al zanjar cosas como conteos de días de vacaciones, facturas de noches de hotel (siempre exclusiva), longitudes de contrato de alquiler o periodos de devengo de intereses. También muestra la misma duración en semanas (con días restantes), meses aproximados, años aproximados y horas y minutos totales para precisión de corto rango. Útil para contabilidad precisa de vacaciones, cálculo de plazos de proyecto, verificación de duración de contrato, seguimiento de días desde un evento o simplemente zanjar "cuántos días han pasado realmente desde X".
Sobre esta herramienta
Ambas fechas se parsean como UTC medianoche para evitar que las transiciones de horario de verano añadan o resten un día en el límite. Días totales = `Math.floor((fin - inicio) / 86.400.000)`, y el interruptor inclusivo añade 1 — ese único bit merece pensarlo: los hoteles cobran por noche (exclusivo — una reserva lun-mié son 2 noches), la mayoría de contratos legales cuentan ambos extremos (inclusivo — un contrato lun-mié son 3 días), las políticas de vacaciones varían (revisa la tuya). Semanas = floor de días/7, con los días restantes mostrados al lado. Los meses aproximados usan 30,4375 días (= 365,25/12, la aproximación del año juliano); los años aproximados usan 365,25 (juliano; el año gregoriano exacto = 365,2425 días por la reforma Inter gravissimas de 1582, deriva ~11 minutos/año, irrelevante para los cálculos de fecha típicos) — ambos útiles para pensar en orden de magnitud pero deberías confiar en la calculadora de edad dedicada para precisión legal año-y-mes. Horas = días × 24 (porque el parseo UTC evita el DST), minutos = horas × 60. Las fechas pasadas se manejan con `Math.abs` así que intercambiar las entradas da la misma magnitud. Usos comunes: auditoría de noches de hotel (siempre exclusiva), verificación de días de vacaciones (depende de política), conteo de periodo legal (a menudo inclusivo), informes de ciclo de proyecto, días desde hitos, seguimiento de gestación, cálculo de condena cumplida.
- Días entre dos fechas con interruptor inclusivo/exclusivo de fecha final
- Más semanas (con días restantes), meses aproximados, años aproximados
- Horas y minutos totales para precisión de corto rango
- Parseo UTC medianoche — las transiciones DST no añaden/restan un día
- Math.abs te deja invertir inicio/fin sin cambiar la magnitud
- Toggle inclusivo se alinea con convenciones de uso legal, hotelero y de vacaciones
- Recálculo en vivo al cambiar cualquiera de las dos fechas
- Meses aproximados con promedio gregoriano de 30,4375 días
- Sin subida — ambas fechas se quedan en tu navegador
- Útil para noches de hotel, días de vacaciones, contratos, ciclos de proyecto
Gratis. Sin registro. Tus datos permanecen en tu navegador. Anuncios mediante Google AdSense (con consentimiento).
Preguntas frecuentes
¿Por qué las noches de hotel se cuentan diferente que los días de contrato?
Las noches de hotel se cuentan excluyendo el día de salida: una reserva lun→mié (entrada lun, salida mié) son 2 noches (noche del lun + noche del mar, dejando libre la mañana del mié). Las duraciones de contrato y muchos periodos legales son inclusivos de ambos extremos — un contrato lun→mié son 3 días por convención inclusiva común en contratos legales (se cuentan ambos extremos). Las políticas de vacaciones varían: algunos centros de trabajo cuentan ambos extremos (5 días laborables para vacaciones lun→vie), otros cuentan solo días laborables (excluyendo fines de semana dentro del rango), otros excluyen el día de regreso. El interruptor de esta herramienta usa el modo exclusivo por defecto (igual que la convención hotelera) y suma 1 si lo cambias a inclusivo. Trampas comunes: los contratos de alquiler suelen mezclar (días de renta = inclusivos, devolución de fianza = exclusiva); las pólizas de seguro cuentan desde fecha de efecto inclusiva hasta fecha de expiración exclusiva; las hipotecas devengan interés de forma distinta entre jurisdicciones.
¿Por qué usar parseo UTC medianoche en lugar de hora local?
Las transiciones de horario de verano pueden añadir o restar un día en el límite si calculas duraciones en hora local. La primavera UE (último domingo de marzo, +1 hora) hace que los relojes salten de 01:00 a 03:00 en CET, así que una "duración de 1 día" calculada como diferencia en hora local puede salir 23 horas en lugar de 24; el otoño da 25 horas. El DST del Reino Unido sigue el mismo patrón UE; el de EE.UU. va en domingos distintos (segundo domingo de marzo, primer domingo de noviembre). Las fechas del hemisferio sur corren al revés (DST australiano empieza octubre, termina abril). Parsear ambas fechas como UTC medianoche (00:00:00Z) evita todo eso — la diferencia en milisegundos es exactamente `días × 86.400.000` independientemente de qué fechas calendario caen en DST. El compromiso: si te importa el reloj real durante el cambio de DST (cuántas horas laborables reales), tienes que sumar la corrección de límite manualmente.
¿Qué precisión tiene la aproximación "30,4375 días/mes"?
30,4375 días = 365,25/12, que es la longitud media de mes del año juliano. El valor gregoriano exacto es 365,2425/12 = 30,436875 días/mes — una diferencia de 0,000625 días (~54 segundos) por mes, acumulando ~0,5 hora por año. Para pensar fechas en orden de magnitud ("unos 6 meses desde ahora") la diferencia es invisible. Para amortización de hipotecas a varios años, trabajo actuarial o investigación académica, deberías usar gregoriano exacto 365,2425 con manejo explícito de bisiestos, o una biblioteca que respete el calendario (Temporal API, date-fns, Luxon, day.js como sucesor moderno del obsoleto Moment.js). La salida de "meses aproximados" de la herramienta sirve para estimación de proyecto y conversación humana; para precisión legal/financiera de varios años, usa la calculadora de edad dedicada que calcula años y meses de forma explícita con recorte que respeta el calendario.
¿Por qué ISO 8601 es el único formato de fecha que debería usar programáticamente?
ISO 8601:2019 (formato AAAA-MM-DD) cumple dos propiedades críticas simultáneamente: es inequívoco entre regiones (el "02/03" estadounidense = 3 de febrero, el "02/03" europeo = 2 de marzo — esa conversación nunca pasa en ISO), y es ordenable lexicográficamente como string puro (así "2024-12-31" < "2025-01-01" da el orden cronológico correcto sin parseo). RFC 3339 (Klyne & Newman 2002) es el perfil IETF de ISO 8601 usado por toda la pila web: cabeceras HTTP Date, formato date de JSON Schema, especificaciones OpenAPI, claims JWT iat/exp, timestamps de logs estructurados, fechas de feeds RSS/Atom, columnas TIMESTAMP de bases de datos ISO, Date.prototype.toISOString() de JavaScript. Cuando escribas cualquier fecha a fichero, log o payload de API, usa ISO 8601. Los formatos localizados (31/12/2024, 31.12.2024, 31 dic 2024) solo deberían usarse en la UI final, justo antes de mostrar.
¿Por qué JavaScript Date usa el epoch Unix 1970-01-01?
El epoch Unix 1970-01-01T00:00:00Z (medianoche UTC, 1 de enero de 1970) es el origen de tiempo de referencia del estándar POSIX time_t (IEEE Std 1003.1, revisión actual 1003.1-2024), que Linux, macOS, BSD y la mayoría de sistemas tipo Unix usan como su representación interna de reloj. JavaScript heredó la convención de Java en 1995 y la codificó en ECMA-262 §21.4: el valor interno de un objeto Date es el número de milisegundos desde el epoch, almacenado como flotante de doble precisión IEEE-754. El rango de doble precisión da ±100.000.000 días ≈ ±273.790 años desde el epoch, con precisión de milisegundo (±0,5–1 ms). El epoch se eligió en parte arbitrariamente (el reloj original de Unix en Bell Labs era 1971; el redondeo a 1970-01-01 resultó práctico) y se ha mantenido porque la alternativa — re-anclar a un epoch distinto — rompería décadas de timestamps almacenados en bases de datos, ficheros de log y protocolos.
Fuentes (6)
- International Organization for Standardization (2019). ISO 8601-1:2019 + ISO 8601-2:2019 — Date and time — Representations for information interchange (current edition revising ISO 8601:2004); canonical YYYY-MM-DD format, week-numbering, ordinal-date, time-zone designators. ISO Technical Committee 154 (TC 154); supersedes ISO 8601:2004.
- Klyne, G., & Newman, C. (2002). RFC 3339 — Date and Time on the Internet: Timestamps (IETF profile of ISO 8601 mandated for HTTP Date headers, JSON Schema, OpenAPI, JWT iat/exp, structured logs). Internet Engineering Task Force, Request for Comments 3339, July 2002 (Proposed Standard).
- Ecma International (2024). ECMA-262, 15th edition (June 2024) — ECMAScript Language Specification §21.4 Date Objects: time value as ms since Unix epoch 1970-01-01 UTC, IEEE-754 double precision (range ±100,000,000 days ≈ ±273,790 years from epoch); §21.4.4.25 Date.prototype.setMonth overflow semantics. Ecma International TC39; current standard ECMA-262 published annually since ES5 (2011); Temporal API at TC39 Stage 3 (2026) provides explicit-clamping alternative.
- Pope Gregory XIII (1582). Papal bull Inter gravissimas (24 February 1582) — Gregorian calendar reform: leap year rule (year ÷ 4 AND (not ÷ 100 OR ÷ 400)); 10-day skip 4-15 October 1582 to realign vernal equinox; Gregorian mean tropical year = 365.2425 days (vs Julian 365.25, drift ~11 min/year). Papal States; adopted by Catholic Europe 1582-1584, Protestant nations gradually 1700-1923 (Britain 1752, Russia 1918, Greece 1923).
- 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 canonical reference epoch for JavaScript Date, Linux/Unix system clocks, RFC 3339 'Z' UTC designator. Institute of Electrical and Electronics Engineers / The Open Group joint standard (current revision IEEE Std 1003.1-2024).
- 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. ·