Fecha de fin de meta

Un ritmo diario cero se rechaza con invalid_input en lugar de fingir que el infinito es un plan; también se rechazan ritmos negativos y saldos negativos. El camino es aritmética determinista pura y calendario gregoriano—sin red, sin Date del reloj, sin semilla aleatoria—de modo que el ejecutor gratuito del navegador y la API de prepago devuelven el mismo JSON tras el redondeo decimal fijo cada vez que lo invoque.

Qué significa la fecha de fin de meta con un ritmo diario fijo

Solo aplica la aritmética: remaining es el máximo de cero y goal menos current, days es cero cuando remaining es cero, en caso contrario days es el techo de remaining sobre daily_rate, y completion_date es start_date más esos días del calendario gregoriano sin usar el reloj del anfitrión.

Cómo llamar a la API y qué se devuelve

Días de calendario imposibles como el veintinueve de febrero en un año no bisiesto fallan la validación con un mensaje de campo claro. Envíe un cuerpo JSON con cuatro campos obligatorios: goal (alias target, target_amount, amount), el objetivo numérico no negativo; current (alias current_amount, progress, completed), la cantidad no negativa ya hecha; daily_rate (alias rate, daily_progress, progress_rate), el progreso diario fijo positivo; y start_date (alias date, as_of, current_date), una cadena de calendario ISO estricta YYYY-MM-DD que sea una fecha gregoriana real. Los valores absolutos de dinero o conteo deben permanecer dentro de un billón para que los productos intermedios sigan finitos en doble precisión IEEE en el Worker y en el navegador. El ritmo diario debe ser estrictamente positivo; un valor de cero o casi cero se rechaza con invalid_input porque un ritmo nulo nunca cierra un hueco positivo, y un ritmo negativo también se rechaza. En caso de éxito la respuesta repite goal, current y daily_rate redondeados más el start_date normalizado; fija remaining en la cantidad no negativa aún necesaria; days_needed en el recuento de días enteros; weeks y days_remainder en la división entera de días en bloques de siete; amount_at_rate en días por ritmo diario; completion_date en la fecha ISO proyectada; already_reached en un booleano; formula en la cadena documentada; message en un resumen breve en inglés; y steps en un arreglo ordenado de líneas de sustitución. La validación fallida—campos ausentes, números no finitos, valores fuera de límites absolutos, goal o current negativos, daily_rate cero o negativo, fecha inválida o una proyección que salga del rango de años 0001–9999—devuelve invalid_input y no se cobra. El precio es un fijo $0.002 por petición exitosa con unidad item.

Consejos prácticos, límites y búsquedas relacionadas

Esta página apunta a quien busca una calculadora de fecha de fin de meta, fecha de cierre desde el ritmo diario o remanente dividido por el ritmo en línea; no es una herramienta de meses de ahorro con depósitos mensuales, ni un programador de días hábiles que omite fines de semana, ni un pronóstico Monte Carlo de velocidad. Prefiera esta capacidad cuando ya conozca las tres cifras de progreso y una fecha de referencia y solo necesite el día calendario lineal de cierre; si su plan incluye interés, capitalización o calendarios laborales, use un modelo dedicado. Use la misma unidad para goal, current y daily_rate—no mezcle páginas y palabras, ni dólares y centavos, sin convertir primero. Mantenga el ritmo diario estrictamente positivo; los experimentos gratuitos en el navegador que envíen cero acertarán invalid_input y no se cobrarán en la API. Al enseñar o probar, combine ejemplos: mil de meta con doscientas cincuenta actuales y veinticinco por día desde el primero de enero para un camino exacto de treinta días hasta el treinta y uno; un caso en que el remanente no es múltiplo del ritmo y el techo añade un día extra; un caso en que current ya iguala o supera la meta y days es cero y la finalización coincide con el inicio; y un ritmo diario deliberadamente cero para demostrar el camino duro de invalid_input. Las tareas fallidas que devuelven invalid_input no consumen saldo prepago, lo que mantiene baratos los scripts exploratorios cuando los desarrolladores envían a propósito un ritmo nulo. Las comprobaciones de ida y vuelta son sencillas: recalcule a mano el máximo de cero y goal menos current, divida por daily_rate, tome el techo, sume esos días calendario a la fecha de inicio con una biblioteca gregoriana conocida o un calendario en papel, y confirme que coincide con el completion_date publicado dentro del mismo redondeo a doce decimales en los campos de cantidad.