Budget temps d'itinéraire

La marge, le débordement, l'utilisation et un indicateur fits reviennent avec les heures recommandées par ligne, pour qu'un planificateur humain et un client API partagent une seule arithmétique. Un budget nul ou négatif, un transit ou un repos négatifs, et une paire réservée qui dépasse déjà la journée échouent avec invalid_input au lieu d'inventer un horaire.

Comment le transit et le repos réservés réduisent l'enveloppe des activités

Un budget temps d'itinéraire traite la fenêtre d'éveil comme une enveloppe rigide, non comme une liste de souhaits. Le transit et le repos sont soustraits d'abord car ils ne sont pas facultatifs dans une journée réaliste. Chaque activité conserve un nom et un nombre d'heures prévues afin qu'un bloc du Louvre, un marché et une promenade au fil de l'eau restent distincts. Des heures prévues égales restent égales après l'échelle ; une cathédrale de quatre heures à côté d'un musée de deux conserve le rapport deux pour un. La poussière en virgule flottante est absorbée dans la dernière activité prévue positive afin que les heures recommandées somment exactement le bassin restant lors d'une journée en débordement. Le champ available_hours est cette enveloppe : quatorze heures du petit-déjeuner à l'hôtel, ou dix heures entre un départ tardif et une réservation au dîner. Marcher entre musées, un saut de métro, un taxi vers le belvédère et les minutes perdues aux guichets vivent dans transit_hours. Les repas, un café assis, l'enregistrement à l'hôtel et la pause dont le voyageur a vraiment besoin vivent dans rest_hours. Leur somme est reserved_hours. Ce qui reste est remaining_for_activities, le seul bassin que les arrêts prévus peuvent dépenser. Lorsque la somme prévue tient dans le bassin restant, les heures recommandées égalent les heures prévues et slack_hours est le reliquat inutilisé. Lorsque la somme prévue est plus grande, chaque activité est mise à l'échelle par remaining_for_activities divisé par la somme prévue afin que la journée recommandée se referme encore. L'utilisation peut dépasser cent pour cent lorsque committed_hours tel que prévu dépasse le budget ; c'est le signal de couper, non de prétendre que l'horloge s'étire.

Contrat d'entrée, forme de la réponse et erreurs

Le champ activities est un tableau non vide d'objets, chacun avec un name non vide et un hours fini non négatif, au plus cinquante lignes sur ce chemin parse gratuit. Reliez le formulaire gratuit du navigateur à la planification humaine, et appelez le même contrat depuis un constructeur de voyage lorsque l'automatisation a besoin de chiffres identiques. Envoyez par POST un corps JSON avec quatre champs obligatoires. Le champ available_hours est un nombre fini strictement supérieur à zéro et au plus cent soixante-huit, assez pour une longue journée ou une courte enveloppe de plusieurs jours. Les champs transit_hours et rest_hours sont finis et non négatifs, chacun plafonné aussi à cent soixante-huit. Leur somme ne doit pas dépasser available_hours ; une paire réservée qui mange déjà tout le budget et davantage échoue avec invalid_input car il ne reste aucune enveloppe honnête d'activités à allouer. Champs manquants, listes vides, lignes qui ne sont pas un objet, noms vides, nombres non finis, heures négatives et un budget disponible nul ou négatif échouent avec invalid_input et ne sont pas facturés. En succès le corps répète les trois entrées d'heures, signale reserved_hours, remaining_for_activities, planned_activity_hours, recommended_activity_hours, committed_hours, slack_hours, overflow_hours, un indicateur booléen fits, un status parmi fits, tight ou overflow, utilization_percent, scale_factor et activity_count. Chaque ligne d'activité porte index, name, planned_hours, recommended_hours, share_of_activities et percent_of_day. Method vaut reserve_then_scale. Formula rappelle que remaining égale available moins transit moins rest, puis que recommended_i égale planned_i multiplié par le minimum de un et de remaining sur la somme prévue. Une journée tight est une journée qui tient dont la marge est au plus dix pour cent de available_hours. Les appels API réussis utilisent le prix de base publié $0.002 par élément ; les échecs de validation ne consomment pas le solde prépayé.

Où un budget temps quotidien d'itinéraire trouve son utilité

Le chemin de débordement renvoie une recommandation mise à l'échelle au lieu d'une surréservation silencieuse, ce dont un horaire destiné aux hôtes a besoin avant d'imprimer un tableau. Les étudiants qui construisent une boucle en sac à dos attrapent l'erreur classique d'empiler six attractions dans une journée qui a déjà dépensé trois heures en trains. Associez cet allocateur à des aides de temps de marche ou de distance multi-arrêts lorsque vous connaissez déjà les minutes entre les épingles et qu'il ne reste qu'à faire tenir la journée. Les voyageurs de loisir peuvent coller un samedi brouillon, lire d'un coup d'œil la marge ou le débordement, et abandonner un arrêt avant de réserver des billets horodatés qu'ils n'atteindront jamais. Les voyagistes utilisent un calculateur de budget temps d'itinéraire pour qu'un modèle d'escapade urbaine survive à une fenêtre de lumière hivernale plus courte : gardez les mêmes arrêts prévus, augmentez transit_hours lorsque le groupe marche plus lentement, et relancez. Les organisateurs de séminaires d'entreprise réservent le déjeuner et la navette d'hôtel comme rest et transit, puis voient si trois ateliers tiennent encore dans une journée de dix heures. Parce que l'implémentation est parse de niveau A pure, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle ni réseau sortant.