Bonjour,

Avant toute chose : *OUI*, j'ai lu la FAQ sur la façon dont OF calcule les heures de lever/coucher du soleil :-)

J'ai un problème avec les valeurs obtenues par OF pour les heures SR/SS. Quand j'ouvre le cahier journalier à aujourd'hui par exemple, j'ai les heures suivantes :
* jour aéronautique : 07h37
* lever du soleil : 08h01
* coucher du soleil : 20h05
* nuit aéronautique : 20h29

Quand je vais au mardi 4 août, j'obtiens :
* jour aéronautique : 07h37
* lever du soleil : 08h00
* coucher du soleil : 20h05
* nuit aéronautique : 20h28

Le plus curieux, c'est qu'en chechant dans le code (classes/srss/CalculatedSrssSource.php) pour déboguer, je me rends compte que la date utilisée pour calculer les heures est invariablement le ... 13 décembre 1901 !

Une idée ?

Merci bien :-)
Cordialement,

Romain

PS : OF2.0-svn, rev 7102



Modifié 2 fois. Dernière modification le 27/07/09 14:27 par Mr_Smoke.

Ceci ne provient pas de la façon dont OF calcule les heures mais de votre configuration

Sur notre serveur 2.0 aujourd'hui à Cherbourg Maupertus
* jour aéronautique : 05h52
* lever du soleil : 06h34
* coucher du soleil : 21h49
* nuit aéronautique : 22h31

Bonjour,

Je ne vois justement pas ce qui "cloche".
Le code est celui récupéré par SVN. Les préférences du club sont tout ce qu'il y a de plus standard, le fichier de configuration aussi. J'espérais avoir l'avis d'un programmeur pour éviter de monter tout un environnement de debug en fait. Actuellement, en ajoutant quelques var_dump() vite fait, je me suis rendu compte que la valeur de $date passée à CalculatedSrssSource->getSRSS() était invariablement le 1901-12-13 à 20:45. Je vais donc devoir remonter dans le code pour savoir qui passe cette variable et pourquoi elle contient un tel timestamp. Si un codeur a la réponse et veut m'épargner cette recherche, je suis preneur =)

Cordialement,

Romain

Bonjour,

J'ai poussé un peu plus loin le debug. Il semble que le souci vienne de OfDate->getTS() : la date en elle-même est correcte dans l'objet, mais getTS renvoie le fameux timestamp du 13-12-1901.

Sauf erreur, getTS fait appel à getDate de PEAR. J'ai vérifié deux fois, *toutes* les versions des packages PEAR sont celles recommandées. Je vais donc devoir creuser plus loin. Encore une fois, n'hésitez pas si vous avez des suggestions :-)

Cordialement,

Romain

PS : Le wiki est planté ? nginx demande un mot de passe ... Heureusement qu'il y a le cache de Google pour lire la doc !

Bonjour,

En fait j'ai fait fausse route. En changeant l'indicateur OACI de notre terrain, je me suis rendu compte que les heures étaient OK pour d'autres terrains que le nôtre. Reste à savoir pourquoi ça ne marche pas avec LFPP ...

Je soupçonne un problème lors de la mise à jour de la base de données, juste comme ça. Pour info, OF situe visiblement LFPP dans la FIR DGAC (Accra) au vu des coordonnées en degrés (lat : 0.100000042858 long : 0.733334411566) ...

Je continue !



Modifié 1 fois. Dernière modification le 01/08/09 11:42 par Mr_Smoke.

Résolu !

Pour une raison que j'ignore (et que je vais continuer à ignorer ...), les coordonnées de LFPP étaient totalement fausses. En corrigeant ça dans la base de données, tout va mieux.

Ceci n'explique cependant pas pourquoi la fonction OfDate->getTS() renvoie un timestamp totalement erroné, mais ça, c'est une autre histoire.

Bonne journée,

Romain