Trier un tableau de dates

[Jan]

Bonjour,

J'ai un tableau de dates, que je veux trier par ordre décroissant (de la plus récente à la plus ancienne).

Le problème est que ces dates n'ont pas toutes le même format. Certaines sont sous la forme:

Tue, 28 Mar 2006 19:33:37 GMT

... d'autres sous la forme:

28/03/2006 18:10

Je cherche à les mettre toutes au même format, puis à trier le tableau.

Merci.

[Anonymus]

Salut,

Quitte à faire les choses bien, commence par les passer toutes au format timestamp. Le classement ultérieur n'en sera que plus facile.

Pour cela, il te faut utiliser la fonction mktime :

int mktime ( [int hour [, int minute [, int second [, int month [, int day [, int year [, int is_dst]]]]]]])

Pour la date : 28/03/2006 18:10, ca donnera :

$timestamp = mktime(18,10,0,03,28,2006);

Ensuite, tu tries sur le timestamp.

Est ce bien utile de te rappeler la fonction substr ?

string substr ( string string, int start [, int length])

Nico.

[Jan]

Je crois que j'ai compris le principe.

Merci

[Jan]

Je me permet de revenir sur ce sujet pour préciser un point.

Je récupère bien les 3 lettres représentant le mois ("Mar" pour le mois de mars) par la fonction substr, comme suggéré par Anonymus.

Pour convertir ce "Mar" en "03", je balaye ensuite par une boucle while une table de correspondance:

"Jan -> "01"

"Feb -> "02"

etc...

"Dec" -> "12"

Ca fonctionne, mais ce n'est pas très élégant. Je me demandais s'il n'existait pas une fonction toute faite en PHP qui ferait cette conversion.

Merci.

[Dan]

Je pense que tu devrais plutôt utiliser strtotime() pour toutes les convertir en timestamp.

Une fois le tri effectué, tu peux les afficher avec la fonction strftime() qui utilise les LOCALES (si tu veux les noms en français), et te permet toute liberté quant-au format de sortie

Dan

[destroyedlolo]

:!: Attention car sur certains systems, les timestamp sont des entiers signees. Ce qui fait que la date de la veille ... peut etre superieur a celle du jour

De mon cote, plutot que d'utiliser les timestamp, j'utilise une classe maison ou les dates sont au format AAAAMMJJ : le trie est simple, c'est facile aussi a lire pour le debug et je m'en sert meme pour generer des fichiers pour les trucs genre blog.

Par contre, je convertis en timestamp lorsque je valide une date ou lorsque je l'affiche.

Comme je le disais, j'ai fait une classe pour ca (base sur ce que j'avais fait en C++ ) comme ca je n'ai meme pas besoin de m'embeter.

[NorSeb]

Bonjour,

:!: Attention car sur certains systems, les timestamp sont des entiers signees. Ce qui fait que la date de la veille ... peut etre superieur a celle du jour 

Tu veux dire que, en PHP, la fonction time peut renvoyer des valeurs différentes en fonction du système ??

[destroyedlolo]

Bonjour,

Tu veux dire que, en PHP, la fonction time peut renvoyer des valeurs différentes en fonction du système ?? 

<{POST_SNAPBACK}>

ben, il utilise la fonction mktime du system, donc je ne vois pas pourquoi ca ne serait pas le cas.

Apres, je n'ai pas verifier avec PHP, mais je me souviens d'avoir eu ce genre de probleme en C.

[NorSeb]

Franchement je ne vois pas comment c'est possible. Time() renvoi le nombre de secondes écoulées depuis le 1er janvier 1970... Je ne vois donc pas comment ce que tu décris peut arriver. (je me répète c'est l'age )

[destroyedlolo]

Ben, c'est tout simple.

time_t time();

et

typedef long int time_t;

Si pour le compilo que tu utilises, les entiers sont signes par defaut ... ben ca done

long int time();

Bref, des que tu depasses 2^31 secondes ecoulees depuis le 1 janvier 70, le resultat devient un nombre negatif.

[Jan]

J'ai mis en place la solution proposée par Dan... et découvert au passage la fonction strtotime() qui correspond exactement à ce que je cherchais. Mon code est allégé.

Merci à tous pour votre aide.

[Dan]

Pour aller dans le sens de Destroyedlolo, il y a effectivement une mauvaise déclaration pour la structure time_t... le nombre de secondes maximum que peut recevoir un timestamp est de 2^31 et non (2^32 -1) s'il s'agissait d'un entier long non signé.

Cela fait tout de même 2147483648 secondes depuis le 1er janvier 1970, ce qui nous mène à l'année 2038.

C'est d'ailleurs pour cette raison que les serveurs Unix n'ont pas été impactés par le bug de l'an 2000, mais risquent de l'être par le bug prévu en 2038

Dan

[destroyedlolo]

Pour aller dans le sens de Destroyedlolo, il y a effectivement une mauvaise déclaration pour la structure time_t... le nombre de secondes maximum que peut recevoir un timestamp est de 2^31 et non (2^32 -1) s'il s'agissait d'un entier long non signé.

Cela fait tout de même 2147483648 secondes depuis le 1er janvier 1970, ce qui nous mène à l'année 2038.

C'est d'ailleurs pour cette raison que les serveurs Unix n'ont pas été impactés par le bug de l'an 2000, mais risquent de l'être par le bug prévu en 2038

Dan

<{POST_SNAPBACK}>

Pas exactement.

Les systemes avec des time_t signe sont deja dans le negatif depuis 2004 je pense (justement a la fameuse seconde 2147483648).

Mais cela n'a aucun impacte sur les API systeme comme mktime() ou difftime() qui les prennent en compte. Le seul probleme est si l'on essaie de comparer 2 dates en faisant h1 < h2 donc ... c'est toujours plus sur d'utiliser les API

Par contre, comme le disait DAN, tous auront un probleme en 2038 (2^32 secondes apres 1970) mais une bonne partie des Unix rescents sont passe en 64 bits meme pour les time_t.

Modifié 1 Avril 2006 par destroyedlolo