Orçamento de tempo do roteiro

Folga, transbordo, utilização e um indicador fits voltam com as horas recomendadas por linha, para que um planejador humano e um cliente API compartilhem uma só aritmética. Orçamentos nulos ou negativos, trânsito ou descanso negativos, e um par reservado que já ultrapassa o dia falham com invalid_input em vez de inventar um horário.

Como o trânsito e o descanso reservados encolhem o envelope das atividades

Um orçamento de tempo de roteiro trata a janela de vigília como um envelope rígido, não como uma lista de desejos. Trânsito e descanso são subtraídos primeiro porque, num dia realista, não são opcionais. Cada atividade guarda um nome e uma cifra de horas planejadas para que um bloco do Louvre, um mercado e um passeio fluvial continuem distintos. Horas planejadas iguais continuam iguais depois da escala; uma catedral de quatro horas ao lado de um museu de duas conserva a razão dois para um. A poeira de ponto flutuante é absorvida na última atividade planejada positiva para que as horas recomendadas somem exatamente o poço restante num dia de transbordo. O campo available_hours é esse envelope: catorze horas do café da manhã ao hotel, ou dez horas entre uma saída tarde e uma reserva para jantar. Caminhar entre museus, um pulo de metrô, um táxi até o mirante e os minutos perdidos na bilheteria ficam em transit_hours. Refeições, um café sentado, o check-in do hotel e a pausa de que o viajante realmente precisa ficam em rest_hours. A soma é reserved_hours. O que resta é remaining_for_activities, o único poço que as paradas planejadas podem gastar. Quando a soma planejada cabe no poço restante, as horas recomendadas igualam as planejadas e slack_hours é o remanescente sem uso. Quando a soma planejada é maior, cada atividade é escalada por remaining_for_activities dividido pela soma planejada para que o dia recomendado ainda feche. A utilização pode passar de cem por cento quando committed_hours conforme o plano estoura o orçamento; esse é o sinal para cortar, não para fingir que o relógio estica.

Contrato de entrada, forma da resposta e erros

O campo activities é um array não vazio de objetos, cada um com um name não vazio e um hours finito não negativo, no máximo cinquenta linhas neste caminho parse gratuito. Ligue o formulário gratuito do navegador ao planejamento humano e chame o mesmo contrato de um construtor de viagens quando a automação precisar dos mesmos números. Envie por POST um corpo JSON com quatro campos obrigatórios. O campo available_hours é um número finito estritamente maior que zero e no máximo cento e sessenta e oito, o bastante para um dia longo ou um envelope curto de vários dias. Os campos transit_hours e rest_hours são finitos e não negativos, cada um também limitado a cento e sessenta e oito. A soma não pode ultrapassar available_hours; um par reservado que já come o orçamento inteiro e mais falha com invalid_input porque não resta um envelope honesto de atividades para alocar. Campos ausentes, listas vazias, linhas que não são objeto, nomes em branco, números não finitos, horas negativas e um orçamento disponível nulo ou negativo falham com invalid_input e não são cobrados. Em sucesso o corpo ecoa as três entradas de horas, informa reserved_hours, remaining_for_activities, planned_activity_hours, recommended_activity_hours, committed_hours, slack_hours, overflow_hours, um indicador booleano fits, um status de fits, tight ou overflow, utilization_percent, scale_factor e activity_count. Cada linha de atividade traz index, name, planned_hours, recommended_hours, share_of_activities e percent_of_day. Method é reserve_then_scale. Formula reafirma que remaining é available menos transit menos rest, e que recommended_i é planned_i vezes o mínimo de um e remaining sobre a soma planejada. Um dia tight é um dia que cabe cuja folga é no máximo dez por cento de available_hours. Chamadas API bem-sucedidas usam o preço base publicado US$ 0,002 por item; falhas de validação não consomem saldo pré-pago.

Onde um orçamento diário de tempo do roteiro vale a pena

O caminho de transbordo devolve uma recomendação escalada em vez de um overbook silencioso, que é o que um horário voltado ao hóspede precisa antes de imprimir um quadro. Quem monta um circuito de mochilão pega o erro clássico de empilhar seis atrações num dia que já gastou três horas em trens. Emparelhe este alocador com ajudantes de tempo a pé ou de distância com várias paradas quando você já souber os minutos entre os pinos e só precisar que o dia some. Quem viaja a lazer pode colar um sábado rascunho, ler de um relance a folga ou o transbordo e largar uma parada antes de reservar ingressos com horário que nunca alcançará. Operadoras de turismo usam uma calculadora de orçamento de tempo do roteiro para que um modelo de city break sobreviva a uma janela de luz de inverno mais curta: mantenha as mesmas paradas planejadas, aumente transit_hours quando o grupo andar mais devagar e execute de novo. Quem organiza retiros corporativos reserva almoço e o traslado do hotel como rest e transit e vê se três oficinas ainda cabem num dia de dez horas. Como a implementação é parse de nível A pura, cada chamada bem-sucedida custa o preço base publicado US$ 0,002 sem tokens de modelo e sem rede de saída.