Presupuesto de tiempo del itinerario

La holgura, el desborde, la utilización y un indicador fits vuelven con las horas recomendadas por fila, de modo que un planificador humano y un cliente API compartan una sola aritmética. Presupuestos nulos o negativos, tránsito o descanso negativos, y un par reservado que ya supera el día fallan con invalid_input en lugar de inventar un horario.

Cómo el tránsito y el descanso reservados reducen el sobre de actividades

Un presupuesto de tiempo del itinerario trata la ventana de vigilia como un sobre rígido, no como una lista de deseos. El tránsito y el descanso se restan primero porque en un día realista no son opcionales. Cada actividad conserva un nombre y una cifra de horas previstas para que un bloque del Louvre, un mercado y un paseo fluvial sigan siendo distintos. Horas previstas iguales siguen iguales tras la escala; una catedral de cuatro horas junto a un museo de dos conserva la razón dos a uno. El polvo de coma flotante se absorbe en la última actividad prevista positiva para que las horas recomendadas sumen exactamente el pozo restante en un día de desborde. El campo available_hours es ese sobre: catorce horas desde el desayuno hasta el hotel, o diez horas entre una salida tardía y una reserva para cenar. Caminar entre museos, un salto de metro, un taxi al mirador y los minutos perdidos en taquilla viven en transit_hours. Las comidas, un café sentado, el check-in del hotel y la pausa que el viajero realmente necesita viven en rest_hours. Su suma es reserved_hours. Lo que queda es remaining_for_activities, el único pozo que las paradas previstas pueden gastar. Cuando la suma prevista cabe en el pozo restante, las horas recomendadas igualan las previstas y slack_hours es el remanente sin usar. Cuando la suma prevista es mayor, cada actividad se escala por remaining_for_activities dividido entre la suma prevista para que el día recomendado aún cierre. La utilización puede superar el cien por ciento cuando committed_hours según lo previsto rebasa el presupuesto; esa es la señal para recortar, no para fingir que el reloj se estira.

Contrato de entrada, forma de la respuesta y errores

El campo activities es un array no vacío de objetos, cada uno con un name no vacío y un hours finito no negativo, como máximo cincuenta filas en esta ruta parse gratuita. Conecte el formulario gratuito del navegador a la planificación humana y llame al mismo contrato desde un constructor de viajes cuando la automatización necesite cifras idénticas. Envíe por POST un cuerpo JSON con cuatro campos obligatorios. El campo available_hours es un número finito estrictamente mayor que cero y como máximo ciento sesenta y ocho, suficiente para un día largo o un sobre breve de varios días. Los campos transit_hours y rest_hours son finitos y no negativos, cada uno también limitado a ciento sesenta y ocho. Su suma no debe superar available_hours; un par reservado que ya se come el presupuesto entero y más falla con invalid_input porque no queda un sobre honesto de actividades que asignar. Campos ausentes, listas vacías, filas que no son objeto, nombres en blanco, números no finitos, horas negativas y un presupuesto disponible nulo o negativo fallan con invalid_input y no se facturan. En el éxito el cuerpo repite las tres entradas de horas, informa reserved_hours, remaining_for_activities, planned_activity_hours, recommended_activity_hours, committed_hours, slack_hours, overflow_hours, un indicador booleano fits, un status de fits, tight u overflow, utilization_percent, scale_factor y activity_count. Cada fila de actividad lleva index, name, planned_hours, recommended_hours, share_of_activities y percent_of_day. Method es reserve_then_scale. Formula reafirma que remaining es available menos transit menos rest, y que recommended_i es planned_i por el mínimo de uno y remaining entre la suma prevista. Un día tight es un día que cabe cuya holgura es como máximo el diez por ciento de available_hours. Las llamadas API correctas usan el precio base publicado $0.002 por ítem; los fallos de validación no consumen saldo prepago.

Dónde un presupuesto diario de tiempo del itinerario aporta valor

La vía de desborde devuelve una recomendación escalada en lugar de un sobrecupo silencioso, que es lo que un horario de cara al huésped necesita antes de imprimir un cuadro. Quienes diseñan una ruta mochilera detectan el error clásico de apilar seis atracciones en un día que ya gastó tres horas en trenes. Empareje este asignador con ayudantes de tiempo a pie o de distancia con varias paradas cuando ya conozca los minutos entre pines y solo necesite que el día sume. Quien viaja por ocio puede pegar un sábado borrador, leer de un vistazo la holgura o el desborde y soltar una parada antes de reservar entradas horarias a las que no llegará. Los operadores turísticos usan una calculadora de presupuesto de tiempo del itinerario para que una plantilla de escapada urbana sobreviva a una ventana de luz invernal más corta: conserve las mismas paradas previstas, suba transit_hours cuando el grupo camine más despacio y vuelva a ejecutar. Quienes organizan retiros corporativos reservan el almuerzo y el traslado al hotel como rest y transit, y comprueban si tres talleres caben aún en un día de diez horas. Como la implementación es parse de nivel A pura, cada llamada exitosa cuesta el precio base publicado $0.002 sin tokens de modelo ni red saliente.