mon calendrier ne passe pas 2039

Bonjour
j'ai fait un calendrier (on peut télécharger le zip ici http://cogiter.info/images/calendrier.zip)
J'aimerais savoir pourquoi il ne passe pas l'année 2039. Il revient à l'année 1970 c'est à dire à 0?
Voici le boutde code ou les années son incrémentées:

Code:

---

1 2 3 4 5 6 7

if (p_Bouton==p_gadget->calend.Bouton[3]) { (tps->tm_year)++; p_gadget->calend.tCalend=mktime(tps); actualiserCalend (p_gadget); }

---

Merci !;)

Edité : j'oublie de dire que le zip, c'est le calendrier pour linux pas pour windows.

ça fait deux messages que je poste et pratiquement personne ne répond, j'ai fait un truc qui fallait pas ? En tout cas vu d'ici je dirais bizarre bizarre, mais c'est peut être une tite parano naissante ;)

Bon pour mon soucis, si ça peut servir à qq'un, je viens de me rendre compte que ça ne doit pas être un problème de GTK+ mais plutôt de C. Pour le 19 janvier 2038 p_gadget->tCalend devient négatif.

time_t doit être limité ou un truc comme ça... je poursuis mes recherches mais de l'aide serait tjrs la bienvenue. :)

Ah ben voilà, j'ai fait un sizeof(time_t), et je me rends compte que c'est comme un int en définitive (32bits). Donc un int c'est compris entre -2 147 483 648 et 2 147 483 647 et on atteint 2 147 483 647 le mardi 19 janvier 2038 à 04H14'07''

Voilà maintenant il reste à trouver une solution pour aller plus loin.

Bon j'ai trouvé un ersatz de solution : comme 1982 ressemble à 2038 (nombre paire mais pas bissextile) quand l'année passe à 2038 je reviens à 1982 et j'ai ajouté une variable dans ma structure que j'utiliserai pour corriger l'année. ça donne ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

if (p_Bouton==p_gadget->Bouton[3]) {   (tps->tm_year)++; if(tps->tm_year==138) { tps->tm_year=82; p_gadget->bug38 = 56; } p_gadget->tCalend=mktime(tps); actualiserCalend (p_gadget); }

---

Dans la fonction "actualiserCalend" pour transformer l'année en chaîne de caractères j'ai écrit :

Code:

---

1 2	sprintf(texte,"%ld",(tps->tm_year+1900+p_gadget->bug38));

---

Pour le bouton retour on fait l'inverse..
On peut aussi ne pas utiliser time-t ...;)

Pourquoi ne pas utilisez GtkCalendar ?

Je suis sous Windows donc sans un minimum de code il est difficile de répondre à ta question ;)

Citation:

---

Envoyé par gege2061

Pourquoi ne pas utilisez GtkCalendar ?

Je suis sous Windows donc sans un minimum de code il est difficile de répondre à ta question ;)

---

Pourquoi ne pas utiliser GtkCalendar ? Parce que je ne savais pas que ça existait ! :lol:
Bon je vais voir ça... c'est en se trompant qu'on apprend à ce qu'il paraît, ..moi j'apprends vite ! :mrgreen:

Merci pour la réponse.

c'est tout a fait normal

le calendrier n'est exploitable que de 1970 a 2039 parce que les appels calendaires en C font appels a des ressources systemes et bios et ni l'un ni l'autre ne peut depasser ses dates...
C'est hardware tu ne peux pas y faire quoi que ce soit hormis ajouter a ton code le calcul specifique aux dates au dela (et en deca) de ces deux limites.

en clair pour depasser ces limites il faut ecrire une couche calendaire integrallement software sans aucun appel au horloges hardware ni au bios ni au system mais integrallement calculees par ton programme lui meme integralement.

la commande cal par exemple fonctionne sur ce principe.

Je pense que ton erreur est tout simplement dûe à ca,

http://fr.wikipedia.org/wiki/Bogue_de_l'an_2038

Il y a forcement un lien , sinon la coincidence me parait trop enorme ;)

Citation:

---

Envoyé par fredsor

Je pense que ton erreur est tout simplement dûe à ca,

http://fr.wikipedia.org/wiki/Bogue_de_l'an_2038

Il y a forcement un lien , sinon la coincidence me parait trop enorme ;)

---

oui la limitation hardware est mise en place pour compenser celà justement

Le fait que le bios soit limité à 2038, c'est une chose, mais ensuite l'OS peut faire un peu ce qu'il veut même si au delà de 2038 il ne pourra plus récupérer facilement mémoriser la date entre les reboots. En tout cas, sur certaines archis 64 bits, linux peut d'ores et déjà supporter des dates au delà de 2038. Par contre, la couche logicielle entre le noyau et les applis, pas forcément :) On retombe à peu près sur ce que tu as dit, je voulais juste préciser un peu