agendas: do not use minimal_booking_time in min_booking_datetime computation (#76303) #65

Merged
ecazenave merged 3 commits from wip/76303-minimal-booking-time into main 2023-04-11 15:53:54 +02:00
Owner
No description provided.
ecazenave force-pushed wip/76303-minimal-booking-time from fcd238a4ab to 067fa6e802 2023-04-06 11:20:38 +02:00 Compare
ecazenave force-pushed wip/76303-minimal-booking-time from 067fa6e802 to 3de9b9c303 2023-04-06 18:30:32 +02:00 Compare
ecazenave changed title from WIP: agendas: do not use minimal_booking_time in min_booking_datetime computation (#76303) to agendas: do not use minimal_booking_time in min_booking_datetime computation (#76303) 2023-04-06 23:12:37 +02:00
lguerin reviewed 2023-04-07 10:32:55 +02:00
@ -1366,0 +1544,4 @@
assert resp.json['data'][-2]['datetime'] == '2023-04-04 09:00:00'
assert resp.json['data'][-1]['datetime'] == '2023-04-04 11:00:00'
# move juste after the first 2023-04-05 slot time
Owner

2023-04-03 ?

2023-04-03 ?
Author
Owner

Heu non. Déjà pas d'évènements déclaré le 3 avril dans le test.

Et sur le fond, l'idée est :

  • les deux assert d'avant vérifient que les derniers crénaux visibles sont le le 5 avril
  • ensuite agenda.minimal_booking_time = None qui passe l'horaire d'ouverture des réservation en mode glissant
  • ces deux assert que tu pointes vérifient que le passage en mode glissant fait disparaître les créneaux du 5 (parce que via freezer il est 00h00)
  • les assert suivants vérifient que à mesure que la journée avance, les créneaux du 5 re-apparaissent
Heu non. Déjà pas d'évènements déclaré le 3 avril dans le test. Et sur le fond, l'idée est : * les deux assert d'avant vérifient que les derniers crénaux visibles sont le le 5 avril * ensuite agenda.minimal_booking_time = None qui passe l'horaire d'ouverture des réservation en mode glissant * ces deux assert que tu pointes vérifient que le passage en mode glissant fait disparaître les créneaux du 5 (parce que via freezer il est 00h00) * les assert suivants vérifient que à mesure que la journée avance, les créneaux du 5 re-apparaissent
Owner

Oui mais non, je ne comprends pas. Tu écris "move after 2023-04-05", et juste dessous, "freezer.move_to('2023-04-03T09:01:00+02:00')"

Oui mais non, je ne comprends pas. Tu écris "move after 2023-04-05", et juste dessous, "freezer.move_to('2023-04-03T09:01:00+02:00')"
Author
Owner

Le commentaire était : "move juste after the first 2023-04-05 slot time".

J'ai changé pour "move a few hours later, juste after the first slot time of a day".

Le commentaire était : "move juste after the first 2023-04-05 slot time". J'ai changé pour "move a few hours later, juste after the first slot time of a day".
@ -2663,0 +2786,4 @@
resp = app.get(api_url)
assert resp.json['data'][-1]['datetime'] == '2023-04-04 13:30:00'
# move juste after the first 2023-04-05 slot time
Owner

2023-04-03 ?

2023-04-03 ?
Author
Owner

Même réponse que précédemment.

Même réponse que précédemment.
@ -2663,0 +2788,4 @@
# move juste after the first 2023-04-05 slot time
# this slots become available
freezer.move_to('2023-04-03T11:01:00+02:00')
Owner

j'ai un doute ici, on ne devrait pas aller jusqu'à 3*24H ? donc jusqu'au 6 avril 2023 à 11H01 ?

j'ai un doute ici, on ne devrait pas aller jusqu'à 3*24H ? donc jusqu'au 6 avril 2023 à 11H01 ?
Author
Owner

Je ne comprends pas ce que tu veux dire.

J'ai vaguement l'impression que ça a un rapport avec le fait que tu supposerais que la borne maximale (jour J + délai de réservation maximal) devrait être incluse.

Si c'est ça, non, elle est bien exclue actuellement (au passage https://dev.entrouvert.org/issues/76360).

Je ne comprends pas ce que tu veux dire. J'ai vaguement l'impression que ça a un rapport avec le fait que tu supposerais que la borne maximale (jour J + délai de réservation maximal) devrait être incluse. Si c'est ça, non, elle est bien exclue actuellement (au passage https://dev.entrouvert.org/issues/76360).
@ -370,3 +370,2 @@
[
('2021-07-09T08:00:00+02:00', datetime.datetime(2021, 7, 13, 8)),
('2021-03-18T07:00:00+01:00', datetime.datetime(2021, 3, 22, 7)),
('2021-07-09T08:00:00+02:00', datetime.datetime(2021, 7, 12, 8)),
Owner

même remarque que plus haut, ça me paraissait bien avant: 4*24H donc si on est 2021-07-09T08:00:00+02:00 ça nous amène bien à 2021-07-13T08:00:00+02:00

même remarque que plus haut, ça me paraissait bien avant: 4*24H donc si on est 2021-07-09T08:00:00+02:00 ça nous amène bien à 2021-07-13T08:00:00+02:00
Author
Owner

Encore borne maximale exclue.

Encore borne maximale exclue.
Owner

Sauf que, dans le cas non flottant, test test_events_datetimes_max_booking_datetime_with_minimal_booking_time:

    agenda = Agenda.objects.create(
        label='Foo bar', kind='events', minimal_booking_delay=0, maximal_booking_delay=3
    )
    ...
    # last slots visible are the one on J + maximal_booking_delay (3) -1
    freezer.move_to('2023-04-03T00:00:00+02:00')
    api_url = '/api/agenda/%s/datetimes/' % agenda.slug
    resp = app.get(api_url)
    assert resp.json['data'][-2]['datetime'] == '2023-04-05 09:00:00'
    assert resp.json['data'][-1]['datetime'] == '2023-04-05 11:00:00'

On se pose le 3 avril à n'importe quelle heure, et on voit tous les créneaux du 5 avril. Ca fait en amplitude horaire entre 2 et 3 jours, 3 jours inclus si on se pose à minuit. Juste qu'on ne dépasse pas du 5, on ne regarde pas le 6 avril, qui est exclu.

Pour moi, si on est dans le cas flottant (avec ici un délai max à 4 jours):
on est au 2021-07-09T08:00:00+02:00, ça donne bien 2021-07-13T08:00:00+02:00, mais on exclut 2021-07-13T08:00:00+02:00: un event posé à 2021-07-13T08:00:00+02:00 n'apparaît pas, un event posé à 2021-07-13T07:59:59+02:00 apparaît

Sauf que, dans le cas non flottant, test `test_events_datetimes_max_booking_datetime_with_minimal_booking_time`: ``` agenda = Agenda.objects.create( label='Foo bar', kind='events', minimal_booking_delay=0, maximal_booking_delay=3 ) ... # last slots visible are the one on J + maximal_booking_delay (3) -1 freezer.move_to('2023-04-03T00:00:00+02:00') api_url = '/api/agenda/%s/datetimes/' % agenda.slug resp = app.get(api_url) assert resp.json['data'][-2]['datetime'] == '2023-04-05 09:00:00' assert resp.json['data'][-1]['datetime'] == '2023-04-05 11:00:00' ``` On se pose le 3 avril à n'importe quelle heure, et on voit tous les créneaux du 5 avril. Ca fait en amplitude horaire entre 2 et 3 jours, 3 jours inclus si on se pose à minuit. Juste qu'on ne dépasse pas du 5, on ne regarde pas le 6 avril, qui est exclu. Pour moi, si on est dans le cas flottant (avec ici un délai max à 4 jours): on est au 2021-07-09T08:00:00+02:00, ça donne bien 2021-07-13T08:00:00+02:00, mais on exclut 2021-07-13T08:00:00+02:00: un event posé à 2021-07-13T08:00:00+02:00 n'apparaît pas, un event posé à 2021-07-13T07:59:59+02:00 apparaît
Author
Owner

"On se pose le 3 avril......3 jours inclus si on se pose à minuit ...on ne regarde pas le 6 avril, qui est exclu."

Je ne comprends pas ton raisonnement, j'en ai un plus simple il me semble : le 3 avril, de 00h00 à 23h59, je ne verrai jamais aucun créneau du 6 avril, les créneaux les plus distants que je voie sont au 5 avril.

C'était déjà le cas avant l'introduction de l'horaire d'ouverture des réservations, ça reste le cas après.

Avec l'horaire d'ouverture des réservations, les créneaux du 5 avril se mettent soit à apparaître tous d'une coup à une heure donnée le 3 avril (à la place de 00h00), soit progressivement au fur et à mesure de la journée du 3 avril.

"Pour moi, si on est dans le cas flottant (avec ici un délai max à 4 jours):
on est au 2021-07-09T08:00:00+02:00 ... 2021-07-13T07:59:59+02:00 apparaît".

Le 2021-07-09 on doit jamais voir les créneaux du 2021-07-13 parce que délai max à 4 jours, peu importe les autres paramètres.

"On se pose le 3 avril......3 jours inclus si on se pose à minuit ...on ne regarde pas le 6 avril, qui est exclu." Je ne comprends pas ton raisonnement, j'en ai un plus simple il me semble : le 3 avril, de 00h00 à 23h59, je ne verrai jamais aucun créneau du 6 avril, les créneaux les plus distants que je voie sont au 5 avril. C'était déjà le cas avant l'introduction de l'horaire d'ouverture des réservations, ça reste le cas après. Avec l'horaire d'ouverture des réservations, les créneaux du 5 avril se mettent soit à apparaître tous d'une coup à une heure donnée le 3 avril (à la place de 00h00), soit progressivement au fur et à mesure de la journée du 3 avril. "Pour moi, si on est dans le cas flottant (avec ici un délai max à 4 jours): on est au 2021-07-09T08:00:00+02:00 ... 2021-07-13T07:59:59+02:00 apparaît". Le 2021-07-09 on doit jamais voir les créneaux du 2021-07-13 parce que délai max à 4 jours, peu importe les autres paramètres.
Owner

(j'abandonne)

(j'abandonne)
Owner

(en partant de l'hypothèse qu'on a posé 3 jours de délai max).

"soit progressivement au fur et à mesure de la journée du 3 avril."
Et justement c'est ça qui me bloque; on devrait voir apparaître les créneaux du 6 avril progressivement au fur et à mesure de la journée du 3 avril, et pas ceux du 5 avril.

Je n'ai aucun problème avec le comportement non flottant, avec ouverture à minuit ou peu importe l'heure définie.

(en partant de l'hypothèse qu'on a posé 3 jours de délai max). "soit progressivement au fur et à mesure de la journée du 3 avril." Et justement c'est ça qui me bloque; on devrait voir apparaître les créneaux du 6 avril progressivement au fur et à mesure de la journée du 3 avril, et pas ceux du 5 avril. Je n'ai aucun problème avec le comportement non flottant, avec ouverture à minuit ou peu importe l'heure définie.
Owner

(et, le ticket décrit un problème de comportement en mode non flottant, mais cette PR impacte le mode flottant, dont le problème que tu essaies de corriger n'a pas été exposé dans la description du ticket)

(et, le ticket décrit un problème de comportement en mode non flottant, mais cette PR impacte le mode flottant, dont le problème que tu essaies de corriger n'a pas été exposé dans la description du ticket)
ecazenave requested review from lguerin 2023-04-11 11:28:26 +02:00
ecazenave force-pushed wip/76303-minimal-booking-time from 3de9b9c303 to c7e9c0cd81 2023-04-11 12:31:24 +02:00 Compare
lguerin refused to review 2023-04-11 12:34:17 +02:00
Owner

Désolé si c'est redite mais j'essaie de comprendre ce qui se passe ici, mais avant ça une note : on vérifie seulement le dernier créneau présenté, pas le premier, pourtant ce ticket vient parce qu'il y avait justement une influence non-désirée sur le premier créneau affiché. De là je me dis que ça serait utile de vérifier le premier créneau affiché.

Mais ce commentaire il s'applique en fait à 0001, qui est le commit "ne pas avoir d'influence sur le premier créneau dispo". Ensuite 0003 vocabulaire, ok.

Reste donc 0002 qui est "change max_booking_datetime implementation" et en fait il ne s'agit pas de juste changer l'implémentation, mais de changer un comportement, et toutes les questions concernent ce point ? Globalement je me sens un peu perdu entre ce qui existait, ce qui a été tenté en #56284, ce ticket.

En partant de l'idée que la migration passe l'existant sur "ouverture à minuit", les comportements seraient :

  • "ouverture à minuit" : le jour J à minuit, tous les horaires du jour J+x apparaissent.
  • "ouverture à 8h" : le jour J à minuit, rien ne se passe, le jour J à 8h, tous les horaires du jour J+x
  • "ouverture pas définie = flottante", le jour J à 8h l'horaire J+x 8h, le jour J à 9h l'horaire J+x 9h, etc.

Est-ce que cette description correspond à avant ce ticket, ou à après ce ticket, ou à rien ?

Désolé si c'est redite mais j'essaie de comprendre ce qui se passe ici, mais avant ça une note : on vérifie seulement le dernier créneau présenté, pas le premier, pourtant ce ticket vient parce qu'il y avait justement une influence non-désirée sur le premier créneau affiché. De là je me dis que ça serait utile de vérifier le premier créneau affiché. Mais ce commentaire il s'applique en fait à 0001, qui est le commit "ne pas avoir d'influence sur le premier créneau dispo". Ensuite 0003 vocabulaire, ok. Reste donc 0002 qui est "change max_booking_datetime implementation" et en fait il ne s'agit pas de juste changer l'implémentation, mais de changer un comportement, et toutes les questions concernent ce point ? Globalement je me sens un peu perdu entre ce qui existait, ce qui a été tenté en #56284, ce ticket. En partant de l'idée que la migration passe l'existant sur "ouverture à minuit", les comportements seraient : * "ouverture à minuit" : le jour J à minuit, tous les horaires du jour J+x apparaissent. * "ouverture à 8h" : le jour J à minuit, rien ne se passe, le jour J à 8h, tous les horaires du jour J+x * "ouverture pas définie = flottante", le jour J à 8h l'horaire J+x 8h, le jour J à 9h l'horaire J+x 9h, etc. Est-ce que cette description correspond à avant ce ticket, ou à après ce ticket, ou à rien ?
Author
Owner

"Est-ce que cette description correspond à avant ce ticket, ou à après ce ticket, ou à rien ?"

Cette description correspond exactement à après ce ticket.

Le comportement introduit par #56284, je ne saurais le décrire exactement, j'ai commencé par constater que "Horaire de réservation minimale : renseigner une heure peut faire apparaitre des cŕeneaux plus lointains et cacher des rdv proches".

Déjà "faire apparaitre des créneaux plus lointains", c'est contraire à la description que tu viens de poser, et puis de toute façon à un moment j'ai arrêté d'essayer de recenser les problèmes, pour me concentrer sur ce qu'on veut que ça fasse, écrire les tests unitaires qui en rendent compte, changer l'implémentation pour que les tests passent.

"Est-ce que cette description correspond à avant ce ticket, ou à après ce ticket, ou à rien ?" Cette description correspond exactement à après ce ticket. Le comportement introduit par #56284, je ne saurais le décrire exactement, j'ai commencé par constater que "Horaire de réservation minimale : renseigner une heure peut faire apparaitre des cŕeneaux plus lointains et cacher des rdv proches". Déjà "faire apparaitre des créneaux plus lointains", c'est contraire à la description que tu viens de poser, et puis de toute façon à un moment j'ai arrêté d'essayer de recenser les problèmes, pour me concentrer sur ce qu'on veut que ça fasse, écrire les tests unitaires qui en rendent compte, changer l'implémentation pour que les tests passent.
Author
Owner

"'soit progressivement au fur et à mesure de la journée du 3 avril.'
Et justement c'est ça qui me bloque; on devrait voir apparaître les créneaux du 6 avril progressivement au fur et à mesure de la journée du 3 avril, et pas ceux du 5 avril."

= en mode floattant, le délai de réservation max serait violé. Je ne comprends pas ce que tu ne comprends pas.

"'soit progressivement au fur et à mesure de la journée du 3 avril.' Et justement c'est ça qui me bloque; on devrait voir apparaître les créneaux du 6 avril progressivement au fur et à mesure de la journée du 3 avril, et pas ceux du 5 avril." = en mode floattant, le délai de réservation max serait violé. Je ne comprends pas ce que tu ne comprends pas.
Author
Owner

@lguerin : en fait maintenant je comprends ce que tu veux dire (tu tiens compte de l'horaire des rdv pour calculer le délai max) mais je ne suis pas du tout d'accord sur le fait qu'on veuille cela.

Pour reprendre la description de Fred, adapté ta sauce (les x + 1 sur la dernière ligne) ça ferait:

  • "ouverture à minuit" : le jour J à minuit, tous les horaires du jour J+x apparaissent.
  • "ouverture à 8h" : le jour J à minuit, rien ne se passe, le jour J à 8h, tous les horaires du jour J+x
  • "ouverture pas définie = flottante", le jour J à 8h l'horaire J+x+1 8h, le jour J à 9h l'horaire J+x+1 9h, etc.

Je ne vois vraiment pas l'utilité de ce x+1 à la place de x ...

@lguerin : en fait maintenant je comprends ce que tu veux dire (tu tiens compte de l'horaire des rdv pour calculer le délai max) mais je ne suis pas du tout d'accord sur le fait qu'on veuille cela. Pour reprendre la description de Fred, adapté ta sauce (les x + 1 sur la dernière ligne) ça ferait: * "ouverture à minuit" : le jour J à minuit, tous les horaires du jour J+x apparaissent. * "ouverture à 8h" : le jour J à minuit, rien ne se passe, le jour J à 8h, tous les horaires du jour J+x * "ouverture pas définie = flottante", le jour J à 8h l'horaire J+x+1 8h, le jour J à 9h l'horaire J+x+1 9h, etc. Je ne vois vraiment pas l'utilité de ce x+1 à la place de x ...
Owner

tu tiens compte de l'horaire des rdv pour calculer le délai max

Heu non, tu vois ça où ?

En fait ça serait plutôt:

  • "ouverture à minuit" : le jour J à minuit, tous les horaires du jour J+(x-1) apparaissent.
  • "ouverture à 8h" : le jour J à minuit, rien ne se passe, le jour J à 8h, tous les horaires du jour J+(x-1)
  • "ouverture pas définie = flottante", le jour J à 8h l'horaire J+x 8h, le jour J à 9h l'horaire J+x 9h, etc.

Il suffit de remplacer x par délai max de réservation = 1 jour pour avoir:

  • "ouverture à minuit" : le jour J à minuit, tous les horaires du jour J apparaissent.
  • "ouverture à 8h" : le jour J à minuit, rien ne se passe, le jour J à 8h, tous les horaires du jour J
  • "ouverture pas définie = flottante", le jour J à 8h l'horaire J+1 8h, le jour J à 9h l'horaire J+1 9h, etc.

Avec ce que tu as codé, si délai max de réservation = 1 jour, en mode flottant, alors on ne voit jamais aucun créneau.

> tu tiens compte de l'horaire des rdv pour calculer le délai max Heu non, tu vois ça où ? En fait ça serait plutôt: * "ouverture à minuit" : le jour J à minuit, tous les horaires du jour J+(x-1) apparaissent. * "ouverture à 8h" : le jour J à minuit, rien ne se passe, le jour J à 8h, tous les horaires du jour J+(x-1) * "ouverture pas définie = flottante", le jour J à 8h l'horaire J+x 8h, le jour J à 9h l'horaire J+x 9h, etc. Il suffit de remplacer x par délai max de réservation = 1 jour pour avoir: * "ouverture à minuit" : le jour J à minuit, tous les horaires du jour J apparaissent. * "ouverture à 8h" : le jour J à minuit, rien ne se passe, le jour J à 8h, tous les horaires du jour J * "ouverture pas définie = flottante", le jour J à 8h l'horaire J+1 8h, le jour J à 9h l'horaire J+1 9h, etc. Avec ce que tu as codé, si délai max de réservation = 1 jour, en mode flottant, alors on ne voit jamais aucun créneau.
Owner

(commentaire posté sans voir les derniers vôtres)

(commentaire posté sans voir les derniers vôtres)
Author
Owner

"Avec ce que tu as codé, si délai max de réservation = 1 jour, en mode flottant, alors on ne voit jamais aucun créneau."

Et en mode non flottant, pour prendre rdv à 9h00, il faut s'être connecté entre 00h00 et 9h00 le jour même, très pratique : c'est un cas complètement irréaliste !

A part ça quel bénéfice ?

Pour les pages de doc, pour les explications à donner aux clients, pour notre cerveau, qu'il ait J+x dans tous les cas (= J+X-1 si x est le délai max), plutôt qu'introduire une variation sur le cas flottant, c'est quand même beaucoup mieux non ?

"Avec ce que tu as codé, si délai max de réservation = 1 jour, en mode flottant, alors on ne voit jamais aucun créneau." Et en mode non flottant, pour prendre rdv à 9h00, il faut s'être connecté entre 00h00 et 9h00 le jour même, très pratique : c'est un cas complètement irréaliste ! A part ça quel bénéfice ? Pour les pages de doc, pour les explications à donner aux clients, pour notre cerveau, qu'il ait J+x dans tous les cas (= J+X-1 si x est le délai max), plutôt qu'introduire une variation sur le cas flottant, c'est quand même beaucoup mieux non ?
Owner

Pour les pages de doc, pour les explications à donner aux clients, pour notre cerveau, qu'il ait J+x dans tous les cas (= J+X-1 si x est le délai max), plutôt qu'introduire une variation sur le cas flottant, c'est quand même beaucoup mieux non ?

Je ne suis pas d'accord; qu'en pensent les CPFs ?

Je trouve plus logique d'expliquer (en supposant pour simplifier qu'il n'y a pas de délai min):

  • en mode non flottant, si vous posez deux jours de délai max, alors passée l'heure de réservation, vous pouvez réserver aujourd'hui et demain
  • en mode flottant, si vous posez deux jours de délai max, alors vous pouvez réserver de tout de suite à 2*24H.
> Pour les pages de doc, pour les explications à donner aux clients, pour notre cerveau, qu'il ait J+x dans tous les cas (= J+X-1 si x est le délai max), plutôt qu'introduire une variation sur le cas flottant, c'est quand même beaucoup mieux non ? Je ne suis pas d'accord; qu'en pensent les CPFs ? Je trouve plus logique d'expliquer (en supposant pour simplifier qu'il n'y a pas de délai min): * en mode non flottant, si vous posez deux jours de délai max, alors passée l'heure de réservation, vous pouvez réserver aujourd'hui et demain * en mode flottant, si vous posez deux jours de délai max, alors vous pouvez réserver de tout de suite à 2*24H.
Owner

J'ajoute ma pierre à l'édifice: je ne m'étais pas tellement intéressé au comportement avec heure, le cas flottant étant pour moi le plus intéressant. Mais à y réfléchir le code Manu est le bon je pense:

  • avant l'heure fatidique (disons 9h) il faut considérer qu'on est encore hier et donc appliquer le délai comme avant jusqu'à minuit mais avec un jour de moins pour le délai,
  • après l'heure c'est le comportement normal d'avant qu'il faut appliquer +delay puis retour à minuit.

L'appliquer à min_booking_datetime, je m'étais posé la question dans le ticket

https://dev.entrouvert.org/issues/56284#note-14

j'ai appliqué le même comportement à min et max_booking_time ça pourrait être discutable, j'ai trouvé que ça donnait une durée fixe entre les deux (modulo les changements d'heure),

mais comme personne n'a voulu trop relire vraiment, voilà. Je suis d'accord que ça a plus de sens de ne pas l'appliquer, c'est vraiment la borne basse qui nous intéresse.

J'ajoute ma pierre à l'édifice: je ne m'étais pas tellement intéressé au comportement avec heure, le cas flottant étant pour moi le plus intéressant. Mais à y réfléchir le code Manu est le bon je pense: * avant l'heure fatidique (disons 9h) il faut considérer qu'on est encore hier et donc appliquer le délai comme avant jusqu'à minuit mais avec un jour de moins pour le délai, * après l'heure c'est le comportement normal d'avant qu'il faut appliquer +delay puis retour à minuit. L'appliquer à min_booking_datetime, je m'étais posé la question dans le ticket https://dev.entrouvert.org/issues/56284#note-14 > j'ai appliqué le même comportement à min et max_booking_time ça pourrait être discutable, j'ai trouvé que ça donnait une durée fixe entre les deux (modulo les changements d'heure), mais comme personne n'a voulu trop relire vraiment, voilà. Je suis d'accord que ça a plus de sens de ne pas l'appliquer, c'est vraiment la borne basse qui nous intéresse.
bdauvergne approved these changes 2023-04-11 15:53:16 +02:00
ecazenave merged commit c7e9c0cd81 into main 2023-04-11 15:53:54 +02:00
ecazenave deleted branch wip/76303-minimal-booking-time 2023-04-11 15:53:54 +02:00
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: entrouvert/chrono#65
No description provided.