bonjour à vous,
 
petit casse tête pour moi aujourd'hui, je cherche à réaliser une conversion de date (format YY/MM/DD,HH/MM/SS)  vers un format UNIX (secondes écoulées depuis le 01/01/1970)....
facile me direz vous... suffit d'utiliser les api date(...) time(...) ou tout autre en fonction du langage utilisé.... mais non
 
c'est pour un system embarqué qui ne connait que les instructions de base, boucle et test
 
dire que 1 an c'est 31556926 secondes et un mois c'est 2629743 secondes ça ne marche pas à cause des décalage bissextile, des mois à 30/31/29 jours...
 
une idée ?
ça doit bien exister quelque part ce genre d’algorithme pour ne pas réinventer la poudre
 

Je pense qu'il va falloir faire le truc à la main quand même.
Tu peux regarder la : Formule de calcul du nombre de jour dans une année

cool, merci.
 
je me disais bien que cette formule devait être quelque part.
 
maintenant reste à espérer que mon system accepte la récursivité

En fait c'est pas trop compliqué à faire à la main, aux calculs du mois de février près, si tu n'as pas à tenir compte des "leap seconds", sinon, ça va vite être prise de tête, comme la page suivante va te le montrer: http://en.wikipedia.org/wiki/Unix_time
A+,

Tiens, j'ai pondu vite fait ceci qui fait le boulot (sans faire de vérification sur la validité des paramètres passés):
 

 
A+,

Le même en version compacte et un poil plus optimisée:

 
A+,

hou purée j'aurai pas fais mieux... ma version était loin d'être optimisée .
 
merci je vais m'en servir volontiers

J'ai fait une petite édition au code:
<< for (i = 1972; i != year; ++i) {
>> for (i = 1972; i < year; ++i) {
ça rajoute deux tours de boucle pas utiles (sauf pour year = 1970 ou 1971), mais permet d"avoir une fonction qui a pour domaine toute la plage des dates valides à partir du 1er Janvier 1970 00:00:00
 
Si tu passes des dates pas nécessairement valides a cette fonction, il faudra au moins vérifier que 1<= month <= 12
 
Il y a surement moyen d'optimiser un peu plus et diviser le nb de boucles par 4  (ne pas faire les tours de boucle inutiles, voire même peut être pas de boucle du tout). Je posterai cela un peu plus tard.
 
A+,

Voila: cette version démarre à la première année bissextile qui suit 1970, et incrémente le compteur de 4 en 4, donc on ne fait pas de tour de boucle inutile.
Au passage, j'ai supprimé aussi l'emploi de la variable, et fait directement l'incrémentation du nb de secondes.
S'il y avait pas de condition zarbi supplémentaire, on pourrait même éviter le boucle et faire une simple multiplication.
 
A+,

mince c'est furieux ça.  
sur quel données tu t'es basé pour pondre un algo pareil ?
 
je suis quand même assez étonné, bravo. j'aimerais bien arriver a faire des algo aussi facilement

Je t'ai ajouté des commentaires dans la toute première version pour que ce soit plus clair.
C'est juste un bête comptage du nb de secondes écoulées depuis le premier janvier 1970 à minuit jusqu'à la date donnée.
 
Ensuite, il y a quelques optimisations pour supprimer les boucles lorsque c'est possible ou ne pas faire de tour de boucle inutile sinon, vu que tu fais de l'embarqué, ou ça peut être important.
 
Si tu as besoin de valider une date avant de la convertir en temps unix, ceci devrait faire l'affaire:

 
Une dernière note: ma fonction date2unix (et la validation de date) ne tient pas compte des leap seconds, ce qui fait qu'au moment ou on insère une leap second (au plus deux fois par an) il peut y avoir un décalage d'une seconde avec le temps unix qui en tient compte. Comme dans la seconde qui suit, le temps unix recule d'une seconde, ce n'est a priori pas important en général, mais c'est à toi de voir si c'est critique pour ton application (si elle se synchronise avec des machines unix qui utilisent un temps unix qui en tient compte), car on a vu des problèmes survenir a cause de cela http://en.wikipedia.org/wiki/Leap_ [...] eap_second
 
EDIT: en y repensant, le code est OK même pour les dates avec une leap second, ce qui me laisse penser que la fonction codée dans les bécanes doit être similaire à la mienne.
par contre, pour validdate, on pourrait modifier le code en faisant le remplacement suivant:
>>      && (0 <= sec)   && ((sec <= 59) || ((sec == 60) && (min == 59) && (hour == 23) && (((day == 30) && (month == 6)) || ((day == 31) && (month == 12)))))
<<      && (0 <= sec)   && (sec <= 59 )
Ce qui validerait des dates correspondant a des leap second (sec vaut 60 les 30 juins et 31 décembre à minuit), ça le validerait aussi pour des années ou on n'a rien ajouté, mais ça ne devrait pas trop prêter à conséquence.
A+,

Tiens en cherchant un peu sur internet, j'au vu que effectivement, ce qui est utilisé est proche de ma fonction:
http://ww1.microchip.com/downloads [...] 01412A.pdf
au détail près que leur implémentation est buggée, puisqu'ils considèrent que une année est bissextile si elle est multiple de 4, ce qui est faux.
 
En cherchant un peu, j'ai trouvé ceci: http://www.madore.org/~david/compu [...] conds.html
tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
    (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
    ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
(ou tm_year est year - 1900 et tm_yday est le numéro du jours dans l'année, en démarrant à 0).
Ça devrait permettre d'optimiser un peu plus le code, il y avait donc moyen de virer la dernière boucle et d'avoir des multiplications...
A+,

Bon ben je crois qu'il est assez difficile ou inutile d'optimiser plus que ceci:

Faire attention à ne pas avoir de troncatures sur ton système, je ne sais pas de quelle taille sont tes ints et tes longs.
Faire aussi attention que ça atteindra sa valeur maximale (si tes longs font au plus 2147483647) relativement rapidement, on en est déjà à 1359480060, donc si c'est pour de l'embarqué spatial ou autre qui doit être encore fonctionnel dans 40 ans...
A+,

 
C'est vrai jusqu'au 28/02/2100 inclus ... D'ici-là, leur code ne sera plus utilisé
 
Le bug de l'an 2038 est beaucoup plus préoccupant !

C'est vrai, mais leur commentaire dans la doc à ce sujet est faux: Leap Year Calculation up to 2399

Clairement, à moins que tout int soit au moins en 64 bits à cette date, mais on peut en douter. Y'aura sans doute des trucs embarqués qui seront encore en activité.
A propos de début de système de datation bizarre, une idée du pourquoi celui des fichier sous DOS/Windows commence le 1er janvier 1601 à minuit?  
EDIT: J'aurais d'abord du regarder sur Wikipedia: http://en.wikipedia.org/wiki/1601
 
A+,

Que ceux qui ont pensé à traiter le cas de l'heure d'été et d'hiver lèvent la main...    
 
Ben oui, suivant la date que tu vas passer en paramètre, tu peux te retrouver avec une heure en moins et donc passer au jour précédent Dans mon appli Astres (cf ma signature), je m'étais basé comme vous sur le nb de secondes par an pour générer, dans une stat, en axe X, des dates comprises entre une date de début et de fin. Ben, perdu.   Suivant les dates en entrée, l'heure d'été et d'hiver peuvent se compenser ou pas. J'ai mis un certain temps à comprendre la cause du bug...

C'est traité dans le code lien suivant que j'avais filé il y a deux ou trois posts: http://ww1.microchip.com/downloads [...] 01412A.pdf
A+,

heureusement pour moi la date que je récupère viens d'un réseau qui n'a pas de décalage été/hiver et est en GMT+0
 
en tout cas merci pour tout

Au cas ou ça intéresse qqu'un voici d'ou sortent les facteurs (((year-1969)/4) - ((year-1901)/100) + ((year-1601)/400))*86400;
En fait, on s'intéresse a la période 1970...year-1  (la contribution de la dernière année dans la formule est donnée par day*86400 (ou day est le yearday, qui démarre à 0))
les facteurs deviennent:
(((year-1-1968)/4) - ((year-1-1900)/100) + ((year-1-1600)/400))*86400;
Et on comprends alors les facteurs:
1968 est la 1e année multiple de 4 avant 1970
1900 est la 1e année multiple de 100 avant 1970
1600 est la 1e année multiple de 400 avant 1970
 
A+,