Time unit

Le problème est simple : il faut être capable de proposer un système de gestion des heures qui permette d'utiliser indifféremment les unités :

- heure et minute

- heure et centième d'heure

Ce qui donne en nombres :

- hh.mm avec hh qui va de 0 à 24 et mm de 0 à 59

- hh.cc avec hh qui va de 0 à 24 et cc de 0 à 99

Il y a correspondance entre les deux par les formules fabuleuses :

<math>mm=\frac{cc}{100 \times 60}</math>

cc=mm/60*100

(je laisse le soin à Mickael de mettre cela en latex ;-)

minutes	centième	centième arrondi
0	0	0
1	1,66	2
2	3,33	3
3	5	5
4	6,66	7
5	8,33	8
6	10	10

On voit donc que le passage des minutes vers les centièmes entraine des erreurs d'arrondi.

Il en est de même dans le sens centièmes vers minutes.

Il faut donc une unité qui permette de stocker à la fois les centièmes et les minutes sans erreur d'arrondi. En effet, la saisie des heures de vol est une opération légale qui ne doit pas souffrir d'imprécision.

La solution consiste à prendre (grosso modo) le PPCM des minutes et des centièmes, ie: PPCM(60,100)=600 (en fait le PPCM est 300 je crois PPCM(60,100)=60*100/PGCD(60,100)=6000/20 mais entre 300 et 600 il y a autant de chiffres, à voir...).

Je préconise donc d'adopter un système "sexacentimal" (hh.sss).

Formules de conversion :

sss=mm*10 et mm=sss/10

sss=cc*6 et cc=sss/6

minute	sexacentième
0	0
1	10
2	20
3	30
4	40
5	50
6	60

Ainsi, on laisse le club libre de choisir son système (et surtout on ne lui demande pas de changer) et ouvre donc le "marché" d'OF à la terre entière et quelques planètes autours.

La conséquence de cela est qu'il faut bien sûr créer une classe qui manipule les sexacentièmes.

L'heure de début de vol sera toujours en minutes et on ne saisira pas l'heure de fin de vol (ou plutot on ne stockera pas l'heure de fin de vol).