Quand y a-t-il quelqu’un pour répondre au téléphone ?

Un horaire qui couvre la ligne téléphonique n’est pas un fait à propos de vos équipes. C’est un fait à propos de vos équipes à une date. Les gouvernements déplacent leurs horloges des fins de semaine différentes et dans des sens opposés : l’écart entre deux de vos bureaux n’est donc pas une constante, et un passage de relais qui tenait tout l’hiver peut cesser de tenir au printemps sans que personne n’y ait touché.

Cette page prend plusieurs équipes, leurs fuseaux horaires nommés et leurs heures locales récurrentes, et calcule ce que cela donne vraiment sur une période : les heures de la journée où quelqu’un est au téléphone, les intervalles où personne ne l’est, le plus long de ces intervalles, et le chevauchement réel de chaque passage de relais.

Planifiez le vôtre

L’horaire chargé ci-dessus est celui avec lequel la page démarre. Trois équipes, Londres, Toronto et Sydney, chacune faisant un quart de huit heures et demie en semaine sur sa propre horloge locale : 06:00 à Londres, 09:00 à Toronto, 09:00 à Sydney. Personne ne travaille de nuit. À elles trois, elles couvrent toute l’horloge de la semaine, avec une demi-heure de chevauchement à chaque passage de relais.

En juillet, ces mêmes trois quarts laissent un trou de 1 h 30 min chaque soir de semaine. Toronto a avancé d’une heure en mars, Sydney a reculé d’une heure en avril, et la demi-heure que les deux partageaient est devenue un trou. Personne n’a changé l’horaire. Personne n’aurait pu le voir dans un tableur d’heures locales de début.

Les deux lignes sont produites en faisant tourner le planificateur de cette page sur les mêmes trois équipes, et les deux mêmes résultats sont des assertions de npm run check:coverage. La ligne de janvier, qui affirme l’absence totale de trou, compte autant que celle de juillet : un vérificateur qui ne trouve jamais que des fautes ne peut pas distinguer un détecteur qui marche d’un détecteur qui se déclenche sur tout.

La façon la plus courante de rater un plan de couverture est de noter un décalage. On regarde Toronto aujourd’hui, on voit UTC-4, on le met dans le tableur, et toutes les dates après le premier dimanche de novembre sont décalées d’une heure. Rien ne plante. Le tableur tombe toujours juste. La personne de garde n’est simplement pas là quand le plan dit qu’elle l’est.

Un décalage est une lecture prise à un instant. Un fuseau est une règle. Les règles vivent dans la base de fuseaux IANA, que chaque navigateur embarque et met à jour, et elles précisent la fin de semaine où chaque région bouge, dans quel sens et de combien. Tous les changements ne valent pas une heure : l’île Lord Howe bouge de trente minutes. Tous les fuseaux ne sont pas à l’heure pile : l’Inde est à trente minutes, le Népal et Eucla à quarante-cinq.

Lisez les deux dernières colonnes plutôt que les trois premières. Toronto et Londres sont à cinq heures d’écart en janvier comme en juillet, et à quatre à la mi-mars et à la fin octobre, parce que pendant ces quelques semaines une région a changé et l’autre non. Toronto et Sydney sont à seize heures d’écart en janvier et à quatorze en juillet, parce que les deux hémisphères bougent en sens inverse et que l’écart varie de deux heures sur l’année.

L’outil refuse donc un décalage fixe en entrée. Taper UTC-5 dans le champ du fuseau donne un message plutôt qu’un plan, ce qui est la réponse honnête : un décalage ne peut pas exprimer une règle récurrente, et un planificateur qui en accepterait un produirait des horaires assurés et faux une partie de chaque année.

Il répond à une seule question : y a-t-il quelqu’un pour répondre au téléphone, et sinon, quand. Ce n’est pas un planificateur de réunions. Il ne cherche pas une heure commode un jour donné pour un groupe de personnes ; il vérifie un horaire récurrent sur une période et signale les trous.

Ce n’est pas non plus un horaire de quarts. Il ne vous dira pas qui fait quel quart, ne respectera les heures contractuelles de personne, ne placera aucune pause et ne remarquera pas que vous avez mis la même personne sur deux quarts à la fois. Il prend les quarts que vous décrivez tels quels et vous dit ce qu’ils couvrent. Bâtir l’horaire est votre travail ; le vérifier est le sien.

Il ne connaît aucun jour férié. Les dates de fermeture se saisissent équipe par équipe, parce que des données mondiales de jours fériés posent un problème de licence et de subdivisions qui n’apporte rien ici, et parce que ce sont de toute façon vos fermetures qui comptent. Et il ne dit rien du nombre de personnes qu’il faut par quart. C’est une autre question, avec une autre réponse, et c’est à cela que sert le calculateur d’effectifs. Celui-ci dit quand quelqu’un est disponible ; celui-là dit combien il en faut.

Chaque extrémité de quart est résolue comme une lecture d’horloge murale à sa propre date locale, en demandant au navigateur ce que marque l’horloge d’un fuseau nommé à un instant candidat, puis en corrigeant jusqu’à ce que les deux concordent. La fin d’un quart est résolue séparément de son début, plutôt que d’être le début plus une durée : c’est pourquoi un quart de nuit dure sept heures la nuit où les horloges avancent et neuf la nuit où elles reculent. Ajouter une durée donnerait huit dans les deux cas, et se tromperait deux fois par an dans des sens opposés.

Deux lectures demandent une décision plutôt qu’une conversion. Le matin où les horloges avancent, une heure locale n’existe pas : une extrémité de quart qui y tombe est placée au moment même du saut, trouvé par dichotomie plutôt qu’en supposant que le pas vaut une heure. Le matin où elles reculent, une heure a lieu deux fois, et la règle est ici que l’horaire ne revendique jamais une couverture que l’horloge n’a pas montrée : la lecture la plus tardive est retenue au début d’un quart et la plus précoce à sa fin, de sorte que le quart rétrécit au lieu de grandir. Chaque quart touché par l’un ou l’autre cas est listé sous « ce que les horloges ont fait », parce qu’un trou qui apparaît une seule nuit de l’année a besoin de sa raison à côté.

Le reste est de l’arithmétique d’intervalles. Les quarts sont fusionnés en heures où quelqu’un est au téléphone ; les heures que vous promettez sont bâties de la même façon dans le fuseau d’affichage ; les trous sont ce qui reste après soustraction. Un passage de relais est le moment où un quart d’une autre équipe reprend le point le plus avancé atteint par la couverture, et son chevauchement est le temps où les deux équipes étaient là ensemble. Un chevauchement négatif est un trou, et un chevauchement de exactement zéro est traité comme un relais tombé plutôt que comme un passage propre, parce que le dernier appel d’un quart peut encore être en cours quand la personne qui l’a pris est partie.

La bande des heures est comptée en minutes réelles et non en cases. Le jour où les horloges avancent, une de ses vingt-quatre heures dure zéro minute et la journée totalise vingt-trois ; le jour où elles reculent, une heure dure deux heures et la journée totalise vingt-cinq. Les deux sont vérifiés par le script, parce qu’un planificateur qui supposerait vingt-quatre heures égales se tromperait exactement les deux jours qu’il existe pour expliquer.

Tout cela tourne dans votre navigateur, en appels Intl et quelques parcours de tableaux. Il n’y a aucun point de terminaison derrière cette page : un horaire dit qui travaille quand et où ces personnes vivent, et cela ne nous regarde pas. Les règles horaires elles-mêmes viennent de la base IANA de votre navigateur et changent quand les gouvernements les changent ; un navigateur qui n’a pas été mis à jour depuis un moment répond donc avec des règles plus anciennes.

Une fois que vous savez quand personne n’est là

Un plan vous dit où sont les trous. Il faut encore que quelque chose décide de ce qu’un appelant entend quand il tombe dedans : vos heures d’ouverture, vos dates de fermeture et un interrupteur pour le jour où ça tourne mal. Cette décision se prend avant que le moindre téléphone sonne, et c’est la même décision, que le trou soit un dimanche ou quatre-vingt-dix minutes un mardi soir de juillet.