Journal Le premier journal du vendredi de l'année (Le Zune plante)

Posté par (page perso) .
Tags : aucun
9
2
jan.
2009
Cher journal,

Pour commencer 2009 dans la tradition, je vais te faire part de ce que j'ai lu ici: http://www.pcinpact.com/actu/news/48168-zune-30go-bug-proble(...) et la suite là: http://www.pcinpact.com/actu/news/48177-zune-plantage-30go-b(...) .

Pour résumé tous les Zunes de la planètes (enfin les modèles 30GB avec le firmware v3 ou plus) ont planté tous ensemble le 31 à minuit. Il semblerait qu'ils n'aient pas supporté le fait que 2008 soit une année bissextile. Tous les appareils ont redémarré et freezé pendant ce redémarrage. Aux dernières nouvelles, les appareils dont la batterie serait totalement vide redémarraient normalement.

Au delà de ce bug de l'an 2000 en retard, je me demande si tout les appareils sont si sensible aux dates. Qu'une erreur de date provoque une erreur, je comprend mais un freeze complet, est-ce courant avec les autres appareils?
  • # Vive les timestamp

    Posté par . Évalué à  7 .

    Heureusement que dans le monde UNIX, on gère le temps en comptant les secondes depuis le 1er janvier 1970... comme ça, les changement d'années sont complètement anodins.
    • [^] # Re: Vive les timestamp

      Posté par . Évalué à  4 .

      Par contre, ça risque d'être difficile courant 2038 pour les machines en 32 bits :-(
      • [^] # Re: Vive les timestamp

        Posté par (page perso) . Évalué à  7 .

        C'est dans 29 ans. Ça laisse un peu de temps. C'est comme si aujourd'hui on avait des problèmes avec des systèmes datant d'avant 1980.
        • [^] # Re: Vive les timestamp

          Posté par . Évalué à  10 .

          Le bug de l'an 2000 était connu depuis au moins 1978. Ca n'a pas empêché de nombreux éditeurs de devoir modifier du code écrit bien après cette date.

          Heureusement que désormais la qualité des matériels et du code est tellement mauvaise que ce qui est écrit/produit maintenant ne fonctionnera pas au delà de 2020.
      • [^] # Re: Vive les timestamp

        Posté par (page perso) . Évalué à  6 .

        Pas tant que ça car time_t est défini sans taille dans l'ISO C. time_t doit juste stocker un temps en seconde et permetre des opérations arithmétiques. En théorie, les programmes devraient être indépendants de la taille de ce type. Donc, à priori, rien n'empêche de redéfinir time_t dans la libc comme un int64_t pour une machine 32bits. Une option -timet64 à gcc pourrait activer une compilation version 64bits. Il y a de fortes chances que tous les programmes du système aient été mis à jour d'ici 30ans.
        • [^] # Re: Vive les timestamp

          Posté par (page perso) . Évalué à  6 .

          il y a de fortes chances que tous les programmes du système aient été mis à jour d'ici 30ans.

          le meme discours était tenu à propos des programmes qu'il a quand meme fallu patché ... car ils n'ont été ni mis à jour ni réécrit.

          donc dans 30 ans quand le cout industriel du patch sera colossal ( une sorte de loi de Moore du budget de la maintenance sous pretexte de normes/controles/validations/... ), on se dira qu'il faut quand meme le faire mais encore une fois à la derniere minute :D
          • [^] # Re: Vive les timestamp

            Posté par (page perso) . Évalué à  3 .

            à la dernière minute ? Tu veux surement dire après l'apocalypse, non ?
            • [^] # Re: Vive les timestamp

              Posté par (page perso) . Évalué à  8 .

              <aparte class="maVie">
              À la fin d'une visite guidée au château d'Angers, qui abrite la tapisserie de l'Apocalypse [1], le guide termine en demandant s'il y a des questions.

              Et là une dame demande sur un ton assez sérieux :

              - et il y a une suite ?

              </aparte>

              [1] : http://fr.wikipedia.org/wiki/Tapisserie_de_l%27Apocalypse
              • [^] # Re: Vive les timestamp

                Posté par . Évalué à  4 .

                Ben, désolé, mais c’est pas si con : l'Apocalypse (ou, pour être précis, ce qui est décrit dans ce « dévoilement »), ce n’est pas la fin de toute chose, c’est un commencement (millénium, nouvelle Jérusalem…).
                • [^] # Re: Vive les timestamp

                  Posté par (page perso) . Évalué à  2 .

                  Certes, l'Apocalypse n'est pas "la fin du monde" tel que généralement entendu ; mais là vu le ton de la question, je ne pense pas que la dame ait voulu engager la discussion sur ce thème...

                  Et puis pour revenir à l a discussion initiale du journal, nous avons déjà passé la date fatidique de l'an 2000 donc, il n'y a plus de fin du monde en vue (sauf pour possesseur de lecteurs Zune).
                  • [^] # Re: Vive les timestamp

                    Posté par . Évalué à  2 .

                    Erreur, d'après les maya... ça arrive bientôt (mais après la fin du monde selon le calendrier Zune...) : le 21/12/2012

                    http://www.211212.info/
                    • [^] # Re: Vive les timestamp

                      Posté par . Évalué à  2 .

                      http://www.211212.info/

                      pas mal, les quelques premières lignes de la page laissent présager le pire, on croit fermement être tombé sur un site de merd....

                      puis survient la vérité.
                      • [^] # Re: Vive les timestamp

                        Posté par (page perso) . Évalué à  2 .

                        [3616 code mylife]

                        J'ai un pote qui crois dur comme fer à ce truc. Ca me frustre tellement de voir un gas doué comme il est pour les sciences, le rationnel, la logique, etc. croire en ses débilités que je ne sais jamais quoi lui dire pour essayer de lui redonner la raison.

                        Ya des arguments en bétons qui contre-disent cette théorie?

                        [/3616 code mylife]
                        • [^] # Re: Vive les timestamp

                          Posté par . Évalué à  3 .

                          Ya des arguments en bétons qui contre-disent cette théorie?
                          Moi, j'en ai un, mais comme ça nécessite d'attendre après la date funeste, je doute donc que quiconque puisse l'utiliser.
                        • [^] # Re: Vive les timestamp

                          Posté par . Évalué à  2 .

                          En CE truc ?

                          Ben tu peux lui dire que c'est manifestement un site parodique, et que les pseudos justifications n'ont même pas le début d'un commencement de justifications elles mêmes ... qu'il y a de l'humour dedans et tout ...
            • [^] # Re: Vive les timestamp

              Posté par . Évalué à  4 .

              Tu veux surement dire après l'apocalypse, non ?

              Non, il veut dire "après l'apocalypse now" :-)
          • [^] # Re: Vive les timestamp

            Posté par (page perso) . Évalué à  1 .

            Il y a une énorme différence entre changer dans la libc (time.h) un
            typedef long time_t;
            en
            typedef int64_t time_t;

            et ensuite, juste recompiler les applis (Ben oui, le travaille à déjà été fait pour les archi 64bits).

            Et le bug de l'an 2000 pour lequel, il a fallu parcourir l'ensemble du code pour trouver les dates codées en 2 chiffres et les fonctions maisons les manipulant.

            Pour Unix, il y a un type global qui doit être utilisé par plus de 99% des programmes et les fonctions qui le manipulent sont standadisées.
            • [^] # Re: Vive les timestamp

              Posté par (page perso) . Évalué à  2 .

              Mouais, enfin on peut pas changer un type aussi facilement : il y a des histoires de compatibilité binaire entre les APIs. De plus, le "format time_t 32 bits signé" est aussi utilisé dans des formats de fichier comme les archives gzip ou le système de fichier ext3. Il faut donc modifier les formats et convertir les fichiers. Heureuseument, ext4 arrive avec ses 64 bits pour les estampilles de temps (enfin !). Windows commence aussi à utiliser 64 bits un peu partout pour le temps.
          • [^] # Re: Vive les timestamp

            Posté par (page perso) . Évalué à  1 .

            >>il y a de fortes chances que tous les programmes du système aient été mis à jour d'ici 30ans.
            >le meme discours était tenu à propos des programmes qu'il a quand meme fallu patché ... car ils n'ont été ni mis à jour ni réécrit.

            Par mise à jour, je ne parlais pas de patcher ou réécrire mais juste de recompiler avec la libc à jour (voir mon post ci-dessus). Rien de comparable.
            • [^] # Re: Vive les timestamp

              Posté par . Évalué à  8 .

              Ca serait beau si c 'etait si simple.

              Le probleme c'est quand tu te retrouves avec une app qui lit/ecrit sa timestamp en binaire dans un fichier.

              Va lire un fichier avec un timestamp 32bit quand ton sizeof(time_t) devient soudainement 8 ...

              Idem si tu transferes ton timestamp par le reseau, combien de gens ont simplement ecrit un recv(socket,timestamp,sizeof(time_t) ) ?

              Si une machine a un time_t 32bit et l'autre 64, ca va etre drole...
              • [^] # Re: Vive les timestamp

                Posté par (page perso) . Évalué à  1 .

                >Va lire un fichier avec un timestamp 32bit quand ton sizeof(time_t) devient soudainement 8 ...
                >Idem si tu transferes ton timestamp par le reseau, combien de gens ont simplement ecrit un recv(socket,timestamp,sizeof(time_t) ) ?

                Pour les 2 exemples, il s'agit de mauvaise programmation et les 2 codes sont déjà défectueux dés maintenant. Pour le premier exemple, la spécification ne spécifie pas de taille pour time_t, donc, il ne faut pas assumer que la taille ne va pas changer. Il est d'ailleurs possible d'avoir plusieurs libc (et/ou compilateurs ) sur un même système et donc, un autre programme, qui accède au fichier, pourrait utiliser un type de 64 bits.

                Le deuxième exemple est encore plus horrible. Sachant qu'on ne transfère jamais sur le réseau sans marshalliser. Le code foire déjà si les deux machines ont une endianess différente ou que d'un coté il y a une machine avec une archi 64bits (ou long - le type souvent choisit pour time_t - est un 64 bits).

                De plus, il y a pas mal d'archi 64bits en prod, en entreprise et dans les chaumières. Et malgré ce métissage, il n'y a pas de problèmes majeurs.

                Pourrais-tu me donner des exemples qui fonctionnent aujourd'hui (et qui ne sont pas déjà défectueux) et qui ne fonctionneront plus en 2038 avec une time_t 64bits et une recompilation ?
                • [^] # Re: Vive les timestamp

                  Posté par (page perso) . Évalué à  1 .

                  Et quand le protocole ou le format de fichier spécifie que le timestamp est codé sur 32 bits ?

                  Et malgré le fait que la pluspart des machine sont maintenant en 64 bits, combien font réelement tourner leurs OS et leurs applications en 64 bits ?
                  Assez peu, car des programmes qui supposent (par erreur) que la taille des pointeurs est 32 bits, il y en a beaucoup. Tout comme il y a beaucoup de programme qui font (par erreur) des conversions de timestamp sur des entiers et inversément.
                  • [^] # Re: Vive les timestamp

                    Posté par (page perso) . Évalué à  2 .

                    >Et quand le protocole ou le format de fichier spécifie que le timestamp est codé sur 32
                    >bits ?

                    Eh bien, ce n'est plus du ressort de unix (ou plutôt de l'ISO C). On peut faire beaucoups de "si". Oui, il y aura toujours quelqu'un pour ne pas respecter le standard. Mais ce n'est pas un bug de 2038 c'est un bug qu'il y ait 2038 ou pas (time_t aurait été implémenté en 64bits directement que ce serait quand même un bug).

                    >Et malgré le fait que la pluspart des machine sont maintenant en 64 bits, combien font
                    >réelement tourner leurs OS et leurs applications en 64 bits ?

                    Quasi tous les solaris ? Tous les irix ?
                    Pas mal de debian ? (http://popcon.debian.org/ )
                    ...

                    C'est non négligeable. Et je le répête, le problème est nettement plus simple que celui du bug de l'an 2000. Même en prenant compte des bugs déjà existants que vous citez, un grep time_t * est possible - ce qui n'était pas le cas pour l'an 2000.
                    • [^] # Re: Vive les timestamp

                      Posté par (page perso) . Évalué à  2 .

                      Tu te focalise sur time_t et sa 'définition'
                      Moi je ne te parle pas de time_t, de l'ISO, de POSIX ou du C, on s'en fou de ça.

                      Le problème est que beaucoup de monde représente les timestamp sur 32 bits (signé). Ce qui ne pause aucun problème aujourd'hui. Ce ne sont pas des bugs aujourd'hui car il n'y a pas de nécessité de représenté des date plus grande que 2038.

                      Le problème est réel ! essaye de changer la date de ton pc en 2038 pour voir. Je te garentil qu'il y aura des problèmes.

                      Certains codaient même le timestamp sur 30 bits ( https://linuxfr.org/2004/01/12/15070.html )
                      • [^] # Re: Vive les timestamp

                        Posté par (page perso) . Évalué à  2 .

                        >Tu te focalise sur time_t et sa 'définition'
                        >Moi je ne te parle pas de time_t, de l'ISO, de POSIX ou du C, on s'en fou de ça.

                        Un timestamp sur un UNIX c'est un time_t et rien d'autre. Ce que tu dis est de la pure mauvaise foi.

                        >Ce ne sont pas des bugs aujourd'hui car il n'y a pas de nécessité de représenté des date
                        >plus grande que 2038.

                        Bien sur qu'il y a nécessité de stocker des dates plus grande que 2038 et surtout des dates dans le passé (avant 1900 - du genre la date de la révolution française). Pour avoir un problème actuellement, il suffit (si c'est du 32 bits) de calculer time(NULL)*2/3 (ben oui le standard autorise les opérations arithmétiques) :
                        time_t size: 4
                        Now: 1231069157
                        t*2/3: -610942994
                        t/3*2: 820712770

                        >Le problème est réel ! essaye de changer la date de ton pc en 2038 pour voir. Je te garentil
                        >qu'il y aura des problèmes.

                        Voilà c'est fait sur mon amd64 et toujours pas de problèmes...

                        Peut-être qu'en 1998
                        http://www.debian.org/News/1998/19980104 n'était pas loin de la réalité.
                • [^] # Re: Vive les timestamp

                  Posté par . Évalué à  2 .

                  Evidemment qu'il s'agit de mauvaise programmation, mais tu connais des gens qui ne font jamais d'erreurs ? La mauvaise programmation comme tu l'appelles, c'est un truc avec lequel il faut vivre, si demain ton kernel arrete de fonctionner a cause d'un bug, mauvaise programmation ou pas, tu l'auras profond.

                  Et le probleme c'est que ce genre de bugs se produit regulierement.

                  cf. http://74.125.95.132/search?q=cache:7hxjPe0AUdYJ:www.irbs.ne(...)

                  pour un exemple deja rapporte.

                  Et plus important : http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/usr.sbin(...)

                  for (res = res0, s = -1; res != NULL; res = res->ai_next) {
                  s = socket(res->ai_family, res->ai_socktype, res->ai_protocol);
                  if (s < 0) {
                  emsg = "socket";
                  continue;
                  }

                  if (connect(s, res->ai_addr, res->ai_addrlen)) {
                  close(s);
                  s = -1;
                  emsg = "connect";
                  continue;
                  }

                  break;
                  }
                  if (s < 0)
                  err(1, "%s", emsg);

                  if (read(s, &tim, sizeof(time_t)) != sizeof(time_t))
                  err(1, "Could not read data");


                  Voila un cas qui clairement posera probleme, et c'est du code en utilisation aujourd'hui donc.
                  J'ai mis 5 minutes avec Google a trouver 2 exemples ou il y a un probleme, tu imagines bien qu'il y a en a beaucoup d'autres.
                  • [^] # Re: Vive les timestamp

                    Posté par (page perso) . Évalué à  4 .

                    >Et le probleme c'est que ce genre de bugs se produit regulierement.
                    >cf. http://74.125.95.132/search?q=cache:7hxjPe0AUdYJ:www.irbs.ne(...)

                    Ils se produisent maintenant et pas en 2038. Il est donc totalement fallacieux de parler de bug de 2038. C'est un bug dans l'absolu. il ne se passera rien de plus en 2038, qu'il ne se passe déja aujourd'hui.


                    >Voila un cas qui clairement posera probleme,

                    Evidement que cela ne posera pas problème car :
                    - ce protocole [1] a été RFCisé en 1983 ce qui est antérieur à la définition de posix [2] (1988) - time_t n'était pas encore défini/formalisé (ANSI C 1989 - ISO C 1990). Il ne s'agit pas de UNIX mais d'autre chose qui n'a rien à voir. Windows et autres sont autant impactés (aussi peu) que UNIX.
                    - plus personne n'utilise ce protocole aujourd'hui car ntp l'a remplacé depuis longtemps.

                    [1] http://tools.ietf.org/html/rfc868
                    [2] http://en.wikipedia.org/wiki/POSIX#Versions
                    • [^] # Re: Vive les timestamp

                      Posté par . Évalué à  0 .

                      Ils se produisent maintenant et pas en 2038. Il est donc totalement fallacieux de parler de bug de 2038. C'est un bug dans l'absolu. il ne se passera rien de plus en 2038, qu'il ne se passe déja aujourd'hui.

                      Et tu es visionnaire et capable de deviner que d'ici 2038 il n'y aura plus aucun bug de ce type ?

                      Evidement que cela ne posera pas problème car :
                      - ce protocole [1] a été RFCisé en 1983 ce qui est antérieur à la définition de posix [2] (1988) - time_t n'était pas encore défini/formalisé (ANSI C 1989 - ISO C 1990). Il ne s'agit pas de UNIX mais d'autre chose qui n'a rien à voir. Windows et autres sont autant impactés (aussi peu) que UNIX.


                      Oui, mais cela n'a rien a voir, au final, passer de 32 a 64bit pour quiconque utilise un soft de ce type aura un impact, les raisons importent peu. Que le soft soit vieux ne change pas le fait que les gens qui l'utilisent encore comptent dessus. Le nombre de societes qui utilisent des softs datant de l'an mille se compte par milliers.

                      - plus personne n'utilise ce protocole aujourd'hui car ntp l'a remplacé depuis longtemps.

                      Plus personne ? Moi je vois qu'il est encore dans les distrib de certains OS, alors dire que plus personne ne l'utilise c'est sacrement ose, la realite est que tu estimes qu'il serait idiot de l'utiliser vu qu'il y a mieux, mais tu ne sais pas si qui que ce soit l'utilise, et il est plus qu'evident que ce n'est pas le seul soft touche.
          • [^] # Re: Vive les timestamp

            Posté par (page perso) . Évalué à  5 .

            Bon, avec un peu de chance on n'enseignera pas le C++ aux indiens et aux chinois d'ici là, comme ça dans 30 ans je pourrai facturer mes services à prix d'or (ben oui, à 60ans faudra bien que je paie ma retraite pour 10-15 ans après).
    • [^] # Re: Vive les timestamp

      Posté par (page perso) . Évalué à  2 .

      Le fait qu'on compte les secondes depuis le 1er janvier 1970 ne change rien, ce genre de bug pourrait très bien se produire sous Linux aussi :
      http://www.codemonkey.org.uk/2008/12/31/leap-seconds/
    • [^] # Re: Vive les timestamp

      Posté par . Évalué à  2 .

      Tiens, d'ailleurs je me demande comment est prise en compte la seconde supplémentaire qui a été rajoutée à la fin de l'année 2008 !

      Quelqu'un a l'info ?
      • [^] # Re: Vive les timestamp

        Posté par . Évalué à  5 .

        Oups, le temps que je pose la question, quelqu'un y a répondu... Linuxfr c'est plus fort que toi !
      • [^] # Re: Vive les timestamp

        Posté par (page perso) . Évalué à  8 .

        Comme ça...

        extrait de /var/log/messages...

        Jan 1 00:52:31 iema01 ntpd[2329]: synchronized to 88.191.14.30, stratum 3
        Jan 1 00:52:31 iema01 ntpd[2329]: kernel time sync status change 4011
        Jan 1 00:53:20 iema01 ntpd[2329]: kernel time sync status change 0011
        Jan 1 00:59:59 iema01 kernel: Clock: inserting leap second 23:59:60 UTC
        • [^] # Re: Vive les timestamp

          Posté par . Évalué à  2 .

          Non mais en fait, je me demandais si cette seconde supplémentaire était comptée ou bien ignorée dans les traduction date <-> timestamp, mais en fait, elle est ignorée :


          $ date --date "2008-12-31 23:59:59 UTC" +"%s"
          1230767999
          $ date --date "2009-01-01 00:00:00 UTC" +"%s"
          1230768000


          Ce qui est après tout assez normal, j'imagine le bordel sinon...
          • [^] # Re: Vive les timestamp

            Posté par . Évalué à  3 .

            Quelque chose m'échappe. Comment ce fait-il qu'une vraie seconde soit intercalée alors que "date" n'en tient pas compte ?
            La seconde en question existe réellement. En fait c'est plutôt le début de l'année qui est décalé d'une seconde afin que tout corresponde pile-poil à la rotation de la terre.

            J'ai essayé en prenant un jour avant et un jour après, au cas où "date" ferait le calcul autrement. Rien de mieux.

            Je constate que des Linuxiens ont eu des problèmes au même moment:
            http://forums.debian.net/viewtopic.php?p=198490&sid=6423(...)
            • [^] # Re: Vive les timestamp

              Posté par . Évalué à  3 .

              Finalement, c'est assez bien expliqué sur la page Wikipedia qui parle du temps Unix : http://en.wikipedia.org/wiki/Unix_time

              En intro ils disent (à propos du timestamp) :

              "It is neither a linear representation of time nor a true representation of UTC (though it is frequently mistaken for both) as the times it represents are UTC but it has no way of representing UTC leap seconds (e.g. 1998-12-31 23:59:60)."

              Qu'on pourrait traduire par :

              "Ce n'est ni une traduction linéaire du temps, ni une traduction de l'heure UTC (même si on le prend souvent pour les deux) puisque l'heure qu'il représente est l'heure UTC, mais qu'il n'a pas moyen de traduire les secondes intercalaires (p. ex 1998-12-31 23:59:60)."

              Puis ils expliquent comment c'est géré au niveau du comptage des secondes (on fait -1 à la fin de la seconde ajoutée).
            • [^] # Re: Vive les timestamp

              Posté par . Évalué à  5 .

              C'est parce qu'une "date" se calcule d'abord en jours, soit le nombre de passages du soleil au méridien, et c'est seulement ensuite que l'on subdivise ce jour en intervalles plus réduits, jusqu'à la seconde.

              D'autre part, la seconde intercalée est une "remise à l'heure", parce que la durée du jour change, alors que la durée d'une seconde doit rester immuable (elle correspond aujourd'hui à 9.192.631.770 périodes d'une radiation émise par l'atome de césium). Ce n'est pas un intercalaire habituel comme ceux du calendrier, qui servent à composer avec le fait que la durée d'une année n'est pas multiple de celle du jour.

              L'utilitaire "date" n'a donc pas besoin d'en tenir compte puisque le nombre de secondes par jour est maintenu. Et par conséquent, le nombre de secondes depuis Epoch l'est aussi. Pour éviter d'avoir à redéfinir, à la place, la durée de la seconde, on a recalé minuit une seconde plus tard, ce qui veut dire que notre minuit règlementaire était en avance par rapport aux étoiles, et que nous sommes maintenant en retard (on garde de la marge pour les prochains réajustements).

              Il est important de remarquer que nous n'avons pas perdu une seconde cette année (ce qui serait inquiétant) mais simplement quelques millisecondes. Seulement, comme le jour est désormais plus long de quelques millisecondes, cette écart va se cumuler avec les années, et il faudra encore insérer des secondes de rattrapage. Et comme la Terre va continuer à ralentir, le phénomène ira en empirant.

              Pour répondre à ta question, donc, non, la seconde intercalée n'existe pas, ou plutôt, elle est censée être la même que la précédente. Elles portent donc toutes deux le même numéro.

              À noter enfin qu'il paraît que l'on n'a pas fait radoter l'horloge parlante, mais que chaque seconde de la dernière minute de 2008 a été 1/60ème de seconde plus longue que d'habitude.
              • [^] # Re: Vive les timestamp

                Posté par . Évalué à  7 .

                cette écart va se cumuler avec les années, et il faudra encore insérer des secondes de rattrapage. Et comme la Terre va continuer à ralentir, le phénomène ira en empirant.
                Pauvres possesseurs de Zune !
    • [^] # Re: Vive les timestamp

      Posté par . Évalué à  3 .

      eureusement que dans le monde UNIX, on gère le temps en comptant les secondes depuis le 1er janvier 1970... comme ça, les changement d'années sont complètement anodins.
      Sauf que sous UNIX beaucoup de timestamp se base sur ce temps depuis le 1er janvier 1970 (CLOCK_REALTIME).
      Or cette horloge peut être amenée à faire des sauts si l'utilisateur change la date, mais pas mal d'appli gère très mal les voyages dans le temps (ou alors ça oblige à avoir un code assez compliqué)...
      Idem quand on sort d'une mise en veille, les applis font un saut brutal dans le futur.

      Posix définit bien une horloge monotone (CLOCK_MONOTONIC) (souvent le temps depuis le boot), mais peu d'API permette de l'utiliser (par exemple les timestamp clavier du noyau Linux sont basé sur la clock realtime)....


      PS : oui ntp est censé éviter les changements brutaux d'horloge, mais par exemple dans le cas d'un système embarqué sans rtc (ie l'horloge n'est pas conservée dans le système est éteint), tous un tas d'applis seront lancées avant que la date réelle soit mise à jour.
      • [^] # Re: Vive les timestamp

        Posté par . Évalué à  4 .

        Or cette horloge peut être amenée à faire des sauts si l'utilisateur change la date, mais pas mal d'appli gère très mal les voyages dans le temps (ou alors ça oblige à avoir un code assez compliqué)...

        Tout ça, c'est de la faute aux codeurs incompétents qui ne savent pas implémenter proprement la recommandation IPoT :-)
  • # Premier troll de l'année

    Posté par . Évalué à  10 .

    est-ce courant avec les autres appareils?

    Non, tant qu'ils n'ont pas été programmés par Microsoft. D'ailleurs, je me demande ce qu'il en est du grille-pain sous NetBSD...

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Premier troll de l'année

      Posté par (page perso) . Évalué à  10 .

      Il s'est arrêté de griller le pain pendant la seconde supplémentaire entre 23h59m59s et 00h00 afin de corriger son horloge interne ce qui a eut pour résultat deux tranche de pain pas parfaitement grillé comme il faut.

      Et pendant ce temps la, les manchot été entrain de pécher leur nourriture sans se soucier de rien (ils n'ont même pas bu le champagne, ni tiré de feu d'artifice au dessus du pôle sud).

      La dernière dépêche AFP nous signale qu'une freebsd s'est complètement vautré comme une loutre a cause d'un driver bourré qui conduisait boggué d'une carte contrôleur.
      • [^] # Re: Premier troll de l'année

        Posté par . Évalué à  -3 .

        en attendant, pendant que les manchots se la dore en pechant, NetBSD est en passe de passer time_t en 64bits et etre un peu plus Y2k38-bug proof.
        • [^] # Re: Premier troll de l'année

          Posté par (page perso) . Évalué à  3 .

          time_t est un long sous Linux, donc sur les archis 64 bits c'est déja en 64 depuis longtemps
          • [^] # Re: Premier troll de l'année

            Posté par . Évalué à  -1 .

            sous Net aussi, merci de me prendre pour un idiot. Je parlais des archis 32bits qui elles, vont utiliser un type 64-bits pour time_t. Il y a une difference (subtile pour toi certainement) entre "les archis 64" et "toutes les archis"
  • # s/bissextile/seconde intercalaire/

    Posté par (page perso) . Évalué à  2 .

    Le problème n'est pas dû au fait que 2008 ait été bisextille, mais au fait qu'une Seconde_intercalaire soit insérée à la fin de l'année 2008.

    La seconde intercalaire sert à ajuster l'heure pour assurer que l'heure civile (calculé grâce à des horloges atomique très précises) soit toujours en concordance avec le [[Temps_universel] basé sur la rotation de la terre sur elle même.

    Les [années_bisextiles] quand à elles, servent à aligner le calandirer avec la prériode de révolution de la terre autour du soleil.

    Ne pas confondre ces deux ajustement donc.
    Voir aussi: Intercalation_(mesure_du_temps)
  • # Le code en cause

    Posté par . Évalué à  5 .

    Le code en cause semblerait être celui-ci :year = ORIGINYEAR; /* = 1980 */

    while (days > 365)
    {
    if (IsLeapYear(year))
    {
    if (days > 366)
    {
    days -= 366;
    year += 1;
    }
    }
    else
    {
    days -= 365;
    year += 1;
    }
    }

    Source : http://blog.makezine.com/archive/2008/12/cause_of_zune_leapy(...)
    (Trouvé dans un commentaire de l'article sur PCINpact)
    • [^] # Re: Le code en cause

      Posté par (page perso) . Évalué à  2 .

      (Je préviens : Je suis fatigué. Ceci est peut-être la réponse à mon incompréhension)

      En lisant ce code, je ne comprend pas pourquoi le bug s'est produit dans la nuit du 31 au 1er et pas dans la nuit du 30 au 31.

      Si j'ai bien compris, le 31 décembre c'est le "days" 366 en année normale et 367 en année bissextile.
      Donc le bug c'est :
      On est le jour 366 (le 31 décembre) et on une année bissextile. Là on rentre dans le premier if mais pas le second et du coup days n'est jamais modifié : boucle infinie.

      Donc c'est quand on passe au 31 (nuit du 30 au 31) et pas au moment du réveillon. Non ?


      (Bon et est-ce que le code est vraiment l'explication ou c'est un fake ?)
      • [^] # Re: Le code en cause

        Posté par (page perso) . Évalué à  2 .

        Le bug c'est produit le 31 à minuit donc dans la nuit du 30 au 31. Pour ce qui est du code, je n'ai aucune idée d'où il vient.

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Le code en cause

        Posté par (page perso) . Évalué à  2 .

        Oui ce code est l'explication.

        Le 31, le nombre de jours écoulés dans l'année 2008 devient supérieur ou égal à 365 donc on reste dans la boucle.

        Par contre a l'intérieur de la boucle ca voit que c'est une année bisextile donc il faut comparer à 366 et pas 365 pour changer d'année et voit donc que l'année n'a pas encore changé et laisse days à 365 et year à 2008. Et comme rien n'a changé, on repart pour un tour de boucle, et comme ça infiniment.

        Donc ca a du foirer tant que days > 365 est vrai et > 366 ne l'est pas, donc pendant toute la journée du 31.

        C'est plus visible avec l'indentation correcte http://fasmz.org/~pterjan/blog/?date=20090103#p01
        • [^] # Re: Le code en cause

          Posté par (page perso) . Évalué à  1 .

          Ouais ok, j'avais donc bien compris le code. C'est juste que pour moi "le 31 à minuit" c'est la nuit du réveillon.
  • # tiens Microsoft a debauche de chez Ubuntu...

    Posté par . Évalué à  2 .

    Ah c'est beau les boites serieuses qui ont de vrai service assurance qualite. Il est absolument impossible pour elles d'avoir des problemes tel que ceux des pseudo-amateurs linuxiens comme Ubuntu. Malheureusement cela fait de la pub gratuite pour ce genre de projet donc il faut se battre du coup Microsoft a decide d'embaucher les responsables qualite de cette petite distribution pour etoffer son propre service et la miracle la comm prevu a fonctionne a plein regime et ils ont commence l'annee sur les chapeaux de roues en ne sachant pas tenir compte des annees bisextiles. Il faut dire que c'est un concept tres (trop?) recent et excessivement complique a mettre en oeuvre. Allez juste pour la route un petit lien:

    http://www.aeroxp.org/2009/01/lesson-on-infinite-loops/

    Le pire c'est que d'autre systeme utilisant Windows CE peuvent etre affecte...
    • [^] # Re: tiens Microsoft a debauche de chez Ubuntu...

      Posté par . Évalué à  3 .

      C'est pas qu'ils ne tiennent pas compte des années bissextiles, c'est juste qu'ils ont décidé de continuer à utiliser leur calendrier... Cf. le bug dans Excel qui considère (considérait ?) que l'année 1900 est bissextile !
      • [^] # Re: tiens Microsoft a debauche de chez Ubuntu...

        Posté par . Évalué à  2 .

        Pas faux ils vivent dans leur propre monde avec leur propre lois de la physique. Ils ne se doutent meme pas qu'il existe un monde parrallele ou les normes existent et sont respectes.

        En tout cas encore une fois on voit le probleme de lecture des normes a Redmond et un exemple flagrant de croire que ses propres "normes" sont meilleurs.
        • [^] # Re: tiens Microsoft a debauche de chez Ubuntu...

          Posté par (page perso) . Évalué à  1 .

          Mais enfin c'est ridicule de dire ça... c'est un bug rien de plus, rien de moins et un bug très con on est d'accord, rien à voir avec l'interprétation (ou non) d'une norme par microsoft ou quelqu'un d'autre... mais juste un dev un peu con, qui a fait une connerie et qui a pas vérifié et donc c'est arrivé sur le produit finis... mais même si microsoft ou tout autre boite ou individu tape dans les mains en désirant que les années / 100 soient bissextiles, ça marchera pas... même si ils le veulent vraiment bcp, et dans ce cas-ci ou le cas excel ça reste un bug point barre (même si dans le cas d'excel, le "support" du bug est dans les versions suivantes pour pouvoir ouvrir les anciens fichier contenant le dit bug).
          • [^] # Re: tiens Microsoft a debauche de chez Ubuntu...

            Posté par . Évalué à  2 .

            Je suis desole mais propager une connerie (il y a pas d'autre mots) tel que le fait que 1900 soit bisextile dans Excel tel que cela continue d'etre fait par microsoft (en particulier dans sa "norme" microsoft OOXML) j'appel pas cela un bug mais enfin chacun a le droit a son opinion.
            • [^] # Re: tiens Microsoft a debauche de chez Ubuntu...

              Posté par (page perso) . Évalué à  1 .

              Et tu appelles ça comment ? Microsoft impose sa vision du monde même quand c'est faux et que tout le monde le sait même Albert ? et t'appelles ta vision de la chose une opinion ? j'appelle ça de la bêtise.
              • [^] # Re: tiens Microsoft a debauche de chez Ubuntu...

                Posté par . Évalué à  1 .

                Tiens par exemple on peut appeler ca une idee de genie puisque tu y tiens. Il n'empeche que pour le reste du monde la definition du calendrier gregorien n'est pas decide a Redmond mais a ete faite il y a quelques siecles.

                Enfin pour reprendre un viel adage:

                Errare humanum est, perseverare diabolicum
                • [^] # Re: tiens Microsoft a debauche de chez Ubuntu...

                  Posté par (page perso) . Évalué à  3 .

                  Il n'empeche que pour le reste du monde la definition du calendrier gregorien n'est pas decide a Redmond

                  Pareil pour microsoft, ils ne décident pas du calendrier grégorien comme pour le reste du monde mais... parce qu'il y a un mais, ils font des bugs, ça oui.

                  Maintenant tu peux continuer à croire que Microsoft veut te faire croire que leurs erreurs sont des faits vérifiés du monde et qu'ils complotent pour te faire adopter leur calendrier grégorien à eux qu'ils ont imaginé au cours d'une réunion pepsi cola... mais dans ce cas, non seulement ce point de vue est une bêtise mais celui qui le maintient est un malade mentale.
                  • [^] # Re: tiens Microsoft a debauche de chez Ubuntu...

                    Posté par . Évalué à  1 .

                    Je pense que tu dois avoir des problemes de lecture et/ou de comprehension du francais car ce n'est pas moi qui ait parle de conservation du calendrier microsoftien...

                    Par contre pour en revenir a ma reponse montre moi ou ce que je dis est faux. Si tu ne me crois pas peut etre croiras tu un expert sur le sujet:

                    http://www.robweir.com/blog/2006/10/leap-back.html

                    donc au lieu de corriger le probleme on le "normalise".

                    Ah ce niveau la c'est plus du bug et c'est ca le pire!
                  • [^] # Re: tiens Microsoft a debauche de chez Ubuntu...

                    Posté par . Évalué à  0 .

                    non seulement ce point de vue est une bêtise mais celui qui le maintient est un malade mentale.

                    d'un autre cote, tu parles de microsoft a Albert la...
                    La logique et le bon sens n'ont pas lieu d'etre ici, c'est un peu la quatrieme dimension.
                    • [^] # Re: tiens Microsoft a debauche de chez Ubuntu...

                      Posté par . Évalué à  1 .

                      Ah tiens ca faisait longtemps lui... Et oui je n'aime pas microsoft et ses afficionados pour la simple et bonne raison que je n'utilise QUE linux et mise a part me faire chier cette boite ne m'apporte rien. Ils sont tellement doues qu'ils sont incapables de faire un logiciel multi-OS, meme leur logiciel mac sont totalement different de ceux pour windows... ne parlons meme pas de l'inexistence totale d'un seul logiciel sur Linux. Cela n'est pas ma faute c'est un choix technico-commercial de LEUR part donc je me tape les emmerdes et aucun aventages (si leur OS est tout pourri MS Office est une suite ok si l'on ne tient pas compte du format) donc en effet cette boite m'enerve car elle ne m'apporte que des ennuis et je suis poli. Du coup les personnes qui font la promotion (voir pire) des logiciels de cette boite sur ce site ont "legerement" le don de m'enerver.
                      • [^] # Re: tiens Microsoft a debauche de chez Ubuntu...

                        Posté par . Évalué à  -1 .

                        Oui oui, papy.
                        T'inquietes pas, les allemands ont ete boutes hors de france, tu peux te calmer, prendre tes pillules roses et aller te coucher (parce que tu as "legerement" le don de nous les gonfler quand t'as tes acces de paranoia).
                      • [^] # Re: tiens Microsoft a debauche de chez Ubuntu...

                        Posté par (page perso) . Évalué à  3 .

                        je n'aime pas
                        je n'utilise
                        me faire chier
                        m'apporte rien
                        ma faute
                        je me tape
                        m'enerve
                        m'apporte
                        je suis
                        m'enerver

                        C'est impressionnant, ton commentaire parle autant de MS que de ton cul. Ton délire paranoïaque contre MS était amusant, maintenant, ça devient lassant.

                        Cordialement

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.