Calculadora de Suma/Resta de Fechas

Una calculadora para sumar o restar fechas obtiene una fecha objetivo moviendo una fecha inicial hacia adelante o hacia atrás por días, semanas, meses o años. Sirve para renovaciones, seguimientos, vencimientos de contratos, garantías, recordatorios y planificación de proyectos sin contar manualmente en el calendario. La parte delicada no es sumar días, sino respetar los límites reales del calendario: los meses tienen longitudes distintas, los años bisiestos cambian febrero y una fecha como el 31 de enero no siempre existe en el mes siguiente. La herramienta da un resultado práctico para planificar rápido. Cuenta tiempo calendario, no días laborables, festivos, reglas regionales ni plazos legales especiales.

La aritmética de fechas en esta herramienta se basa en el calendario gregoriano proléptico tal como lo implementa el objeto Date de ECMAScript. Los meses en JavaScript están indexados desde cero (enero es 0, diciembre es 11), lo cual es la mayor fuente de errores de desfase en código de fechas. Sumar días es sencillo: new Date(d.getTime() + n * 86_400_000). Sumar meses es más difícil porque los meses tienen 28, 29, 30 o 31 días: el patrón estándar date.setMonth(date.getMonth() + n) desborda cuando el mes resultante es más corto que el día de origen, así que el 31 de enero + 1 mes produce el 3 de marzo en lugar del 28 de febrero (el motor traslada los 3 días extra a marzo). Esta herramienta detecta el desborte comparando date.getMonth() después de setMonth y ajusta el día al último día del mes destino cuando es necesario, igualando el comportamiento de moment.js, date-fns y Plain Date.add() de Temporal. Los años bisiestos siguen la regla gregoriana estándar: un año es bisiesto si es divisible por 4, excepto los años de siglo, que deben ser también divisibles por 400. Así, 1900 y 2100 son años comunes, mientras que 2000 fue bisiesto y 2024 también. Esto importa siempre que un cálculo cruce el 29 de febrero: 29 de enero + 1 mes + 1 mes en 2023 da 29 de marzo, pero en 2024 el traspaso pasa por el 29 de febrero (una fecha válida) y luego al 29 de marzo, sin necesidad de ajuste. El corte del año 1582 para la transición juliano-gregoriano se ignora aquí porque el gregoriano proléptico extiende las reglas indefinidamente hacia atrás; las fechas anteriores al 15 de octubre de 1582 son técnicamente anacrónicas pero aun así se calculan correctamente para fines modernos. El manejo de zonas horarias es una dimensión separada: Date almacena un instante UTC internamente y aplica la zona horaria IANA del sistema anfitrión (por ejemplo, America/New_York, Asia/Shanghai) solo al llamar a .getDate(), .month() o .toLocaleString(). De esto se derivan dos trampas: (1) una fecha construida a partir de una cadena ISO sin sufijo Z ("2026-06-10") se interpreta como medianoche UTC, pero "2026-06-10T00:00:00" sin la Z se interpreta como medianoche hora local, y la misma date.getDate() puede devolver 9 o 10 según el desfase del usuario; (2) las transiciones de horario de verano en primavera (saltan 02:00-03:00) y en otoño (repiten 01:00-02:00) hacen que cierta aritmética sea ambigua, por lo que una suma de "+24 horas" puede caer en un reloj que está a 23 o 25 horas de distancia. Para aritmética de días laborables, solo días de semana o con festivos, el resultado calendario aquí debe ser posprocesado contra una lista de festivos específica de la región (por ejemplo, mediante el paquete npm date-holidays o un calendario personalizado) en lugar de depender del traspaso simple.

• Los meses de JS Date están indexados desde cero: enero = 0, diciembre = 11; el error de desfase es el más común.
• Desbordamiento de setMonth: 31 de enero + 1 mes da 3 de marzo, no 28 de febrero; la herramienta ajusta al final del mes comparando getMonth() después de setMonth.
• Año bisiesto: divisible por 4, pero los años de siglo deben ser también divisibles por 400 (así 1900 no, 2000 sí, 2024 sí).
• ISO 8601 sin Z ("2026-06-10T00:00:00") se interpreta como hora local; con Z es UTC, y getDate() puede devolver días distintos.
• Las transiciones de horario de verano crean días de 23 y 25 horas; la suma de +24h no siempre equivale a +1 día calendario.
• El cálculo a nivel de día es exacto mediante getTime() + n * 86_400_000; las unidades mayores se procesan con setMonth/setFullYear y ajuste.
• La aritmética de días laborables y festivos debe aplicarse encima mediante una tabla de calendario regional, no en el motor interno.