Bug du 6 avril 2019

Commentaires

40 commentaires

  • Avatar
    Roland Burnet

    Bonjour,

    Ce n'est pas vraiment un "bug", puisque la même chose s'est passée en 1999.

    Ce sera une opération qui consiste à réinitialiser le compteur de semaine qui actuellement ne peut dépasser 1023, soit 20 ans, d'où la modification en 2019  20 ans après 1999.

    En principe, les appareils fabriqués après 2010 devraient être prévus pour absorber ce changement en douceur. Pour les autres appareils, ce serait surtout la date qui sera affectée mais n'empêcherait pas la localisation ni l'enregistrement de trace, donc moindre mal pour un GPS outdoor, ce sera plus embêtant pour un GPS de voiture qui sera incapable de déterminer l'heure d'arrivée.

    Donc pour un Anima, cela devrait être transparent.

    Cordialement

    R. Burnet

    0
    Actions pour les commentaires Permalien
  • Avatar
    yves andre

    Merci de l'info.

    0
    Actions pour les commentaires Permalien
  • Avatar
    TwoNav Admin

    Bonjour,

    D'accord avec l'explication de Roland.

    De plus, après consultation de nos fournisseurs, nous ne prévoyons pas de problèmes, même avec nos anciens modèles (Sportiva, Delta, Aventura). Même si, si vous détectez un problème, veuillez nous contacter.

    0
    Actions pour les commentaires Permalien
  • Avatar
    Claude-Henri Mussat

    Pour info, le bug existe sur un smartphone Galaxy note 2.

    0
    Actions pour les commentaires Permalien
  • Avatar
    Roland Burnet

    Bonjour,

    Et cela se manifeste comment ?

    Cordialement

    R. Burnet

    0
    Actions pour les commentaires Permalien
  • Avatar
    Claude-Henri Mussat

    Bonjour,

    Cela se manifeste par une date revenue en Août 1999 sur les traces, puisque la date est celle du GPS et non celle du smartphone. Pas encore trouvé si une correction existe.

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    Moi aussi, avec un Samsung Xcover, et sur tablette également.

    Manifestement, le bug existe sur tous les smartphones avec Twonav Android.

    Ce n'est pas un souci du smartphone lui-même, un autre logiciel come Locus se comporte très bien lui.

    0
    Actions pour les commentaires Permalien
  • Avatar
    Jules Savignac

    << Manifestement, le bug existe sur tous les smartphones avec Twonav Android. >>

    Tous heureusement non, mais peut-être les plus anciens : avec Samsung Xcover 2, 3, ou 4, je n'ai pas eu ce souci (mon Xcover a rendu l'âme, donc impossible à tester).

    Quand à savoir si c'est le soft ou TwoNav qui est en cause, je vous renvoie à ce qu'en dit Roland un peu plus haut et à l'article qui suit : https://www.phonandroid.com/certains-gps-sarreteront-de-fonctionner-des-le-6-avril-voici-pourquoi.html Il n'y est nullement question de TwoNav.

     

    0
    Actions pour les commentaires Permalien
  • Avatar
    www.twolandnaviste .fr

    Bonjour à tous,

    Je viens de m'apercevoir que mon "bon vieil Evadéo Médion" enregistre maintenant les traces en 2099. (28 Août au lieu de 13 Avril)

    Et la partie routière indique 1 h 30 pour 11 h 30... (et, de ce fait, l'écran est en mode nuit).

    Cordialement

    Laurent

    PS: Heureusement que Land peut redéfinir le temps,date et l'heure d'une trace.

    0
    Actions pour les commentaires Permalien
  • Avatar
    Roland Burnet

    Bonjour à tous,

    Il manque une publication de Bernard Perrot juste avant celle de Laurent qui incrimine TwoNav de ne pas corriger par soft le défaut des puces GPS qui ne prennent pas la modification de date et repartent donc en 1999.

    Sur mon Xiaomi Redme 3, un enregistrement de trace affiche correctement les dates, donc à coup sûr, si cela marche pour certains appareils et non pour d'autres, c'est que TwoNav n'est pas le seul fautif dans le bug de certains appareils. Leur puce GPS ne communique pas de bonnes informations. Ce serait donc autant au constructeur du smartphone qu'à Twonav de proposer une mise à jour. Certes, comme le dit Bernard Perrot "il suffit de considérer par soft que si la date retourné est antérieure à celle de compilation du logiciel, il faut alors corriger" ce serait une solution, mais qui est tout de même un peu boiteuse car tout les softs du smartphone utilisant les données GPS devraient tenir compte de cette erreur.

    Le niveau des informations fourni par la puce GPS est assez obscur, c'est peut-être indiqué dans le protocole NMEA, mais je n'ai pas encore cherché si c'était vraiment disponible pour tout un chacun.

    Cordialement

    R. Burnet

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    "Ce serait donc autant au constructeur du smartphone qu'à Twonav de proposer une mise à jour."

    Comme je le disais, les autres applications que j'utilise (Locus Map par exemple) affiche un timing correct, c'est donc possible quelque soit le niveau de révision de la puce GPS du Smartphone, et cela prouve qu'au pire, une simple mise à jour de Twonav suffirait. Mais nous savons qu'il ne faut pas compter la-dessus.

    "Le niveau des informations fourni par la puce GPS est assez obscur, c'est peut-être indiqué dans le protocole NMEA"

    Non, cela ne rélève pas du protocole NMEA, dans lequel les dates sont codées de façon "habituelle", c'est a à dire DDMMYY et HHMMSS.mmm. Le "bug" provient du codage de la date sous forme "numéro de semaine", historiquement, codage sous 10 bits seulement par imposition du DoD lors de la libéralisation du signal civil. Ce codage (et son décodage) à lieu en amont, avant génération des trames NMEA.

    Pour revenir à mon Xcover 3 et Locus, celui-ci (Locus) génère des logs NMEA avec des timing corrects, alors qu ewonav buggue.

    0
    Actions pour les commentaires Permalien
  • Avatar
    Roland Burnet

    "Ce codage (et son décodage) à lieu en amont, avant génération des trames NMEA"

    Merci pour cette précision, c'est ce que je voulais dire en disant que les infos données par le protocole NMEA ne sont pas toujours connues.

    "Pour revenir à mon Xcover 3 et Locus, celui-ci (Locus) génère des logs NMEA avec des timing corrects, alors qu ewonav buggue".

    Alors là je ne comprend pas. Pourquoi avant le 6 avril TwoNav prenait bien la bonne date "avec des timing corrects"donnés par NMEA et après non. La il n'y a plus de codage sur 10 bits donc cela devrait marcher. Et ceci d'autant plus que certains smartphones Android avec la même version de TwoNav (3.3.4 pour mon cas)  donnent la bonne date. A éclaircir.

    Cordialement

    R. Burnet

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    "Alors là je ne comprend pas. Pourquoi avant le 6 avril TwoNav prenait bien la bonne date "avec des timing corrects"donnés par NMEA et après non. La il n'y a plus de codage sur 10 bits donc cela devrait marcher. Et ceci d'autant plus que certains smartphones Android avec la même version de TwoNav (3.3.4 pour mon cas)  donnent la bonne date. A éclaircir."

    Je pense que c'est tout simplement parce que le logiciel (Twonav ou autres) ne communique pas en NMEA avec la puce GPS. Par exemple, je viens de tester (toujours avec mon Xcover3) de logguer les trames NMEA avec Locus et avec Ultra GPS Logger : avec Locus, elle sont correctement datées, avec Ultra GPS Logger, elles sont datées en 1999.

    A mon sens, cela confirme ce que je dis depuis le début : c'est le logiciel applicatif qui apporte, ou pas, la correction. Et donc, il suffirait d'une mise à jour de ce logiciel pour que tout rentre dans l'ordre...

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    "Il manque une publication de Bernard Perrot juste avant celle de Laurent qui incrimine TwoNav de ne pas corriger par soft le défaut des puces GPS qui ne prennent pas la modification de date et repartent donc en 1999."

    Oui, je ne comprend rien à comment ce fil est modéré ou pas... j'ai des interventions dans le désordre, et d'autres qui restent en attente de modération depuis deux jours...

    0
    Actions pour les commentaires Permalien
  • Avatar
    www.twolandnaviste .fr

    Bonjour à tous,

    comment ce fil est modéré ou pas...

    Quand il m'arrive d'avoir un post "en attente d'approbation", il suffit d'utiliser le glissé/copié de la souris pour sélectionner le texte, ouvrir une autre réponse, d'y coller le texte, d'envoyer et de supprimer le message en attente. En général, ça marche.

    Il ne faut pas attendre qu'une personne physique de CompeGPS passe par là...

    Edit: Il ne faut pas,aussi, s'attendre à ce qu'une personne physique de CompeGPS passe par là....

    Cordialement

    Laurent

    0
    Actions pour les commentaires Permalien
  • Avatar
    www.twolandnaviste .fr

    Donc, un TN 3.3.4 pour smartphone aurait besoin d'un correctif alors qu'un TN 3.1.1 d'un vieil Aventura (que j'ai) n'en a pas besoin ?

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    "Donc, un TN 3.3.4 pour smartphone aurait besoin d'un correctif alors qu'un TN 3.1.1 d'un vieil Aventura (que j'ai) n'en a pas besoin ?"

    Il semble, oui...

    Je n'ai aucun problème sur mon Anima, ni sur mon ancien Sportiva.

    Il n'est pas difficile d'imaginer que si entre la version Android  et celle des GPS, le code des interfaces et fonctionnalités est issu du même source, celui des drivers est (forcément) différent.

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    Ce message est décalé et fait référence à un précédent d'il y a deux jours, mais il était resté en attente de modération...
    Je suis donc le conseil ci-dessus pour le republier par couper-coller.

    --------------------------------

     

    "Tous heureusement non, mais peut-être les plus anciens : avec Samsung Xcover 2, 3, ou 4, je n'ai pas eu ce souci (mon Xcover a rendu l'âme, donc impossible à tester)."

    Je ne comprends pas bien cette réponse... vous dites ne pas avoir eu de souci avec ces trois modèles, mais sans avoir testé... vous n'en possédez plus, alors qu'il fallait attendre le 7 avril pour savoir...

    Personnellement, je parlais d'un Xcover 3, avec qui il y a le problème de retour en 1999, merci de me croire si vous même n'avez pas essayé !

     

    "Quand à savoir si c'est le soft ou TwoNav qui est en cause"

    Comprend pas non plus... pourquoi opposer "le soft" ou "Twonav", étant entendu que Twonav est un soft.

    Et comme je le disais, sur mon Xcover3, Twonav a le problème, et les autres logiciels que j'y utilise aussi (Locus Maps par exemple) n'ont pas le problème, y compris en enregistrement des données NMEA. Il y a donc bien un problème spécifique avec Twonav.

    Quelque soit l'info brute remontée par le chipset GPS, on peut très bien imaginer que les concepteurs des logiciels ont intégré  la prévision de ce "bug" (il suffit par exemple de considérer par soft que si la date retourné est antérieure à celle de compilation du logiciel, il faut alors corriger), et apporté la correction par logiciel, ce que Twonav n'a pas fait de toute évidence.

    Cordialement,

    0
    Actions pour les commentaires Permalien
  • Avatar
    www.twolandnaviste .fr

    que si la date retourné est antérieure

    Fait "amusant" avec mon vieil Evadéo, lors de l'enregistrement, une date est donnée au nom du fichier, j'ai: 2099-08-28-01.TRK (et je confirme 2099), la liste de points affiche le 28-08-1999

    C'est un TwoNav 2.1.13...

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    Sans doute un driver qui retourne la date sous forme DDMMYY, et qui ajoute arbitrairement "20" pour le siècle et millénaire.

    Le bug de l'an 2000 (qui n'en fut pas un vraiment d'ampleur) était du à ce genre de programmation qui substituait l'arbitraire à un algorithme strict.

    0
    Actions pour les commentaires Permalien
  • Avatar
    www.twolandnaviste .fr

    Entre quoi et quoi voyez-vous "20", je ne comprends pas. SVP.

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    Je veux dire que le driver doit retourner la date sous la forme 990828, qui voudrait dire 28 aout 1999 bug du 6 avril inclu, mais qu'en l'occurence, au lieu d'ajouter 19 (pour le 20e siècle), il ajoute 20 (pour 21e siècle). Dans le premier cas, c'est un "bug du 6 avril" simple, dans celui que vous indiquez, c'est un "bug du 6 avril" cumulé à un "bug de l'an 2000" (inverse...). 

    Bref, de la programmation de gougnafier dans tous les cas !

    0
    Actions pour les commentaires Permalien
  • Avatar
    Jules Savignac

    << Je ne comprends pas bien cette réponse... vous dites ne pas avoir eu de souci avec ces trois modèles, mais sans avoir testé... vous n'en possédez plus, alors qu'il fallait attendre le 7 avril pour savoir... >>

    Non, ce n'est pas ce que j'ai dit. J'ai écrit exactement "avec Samsung Xcover 2, 3, ou 4, je n'ai pas eu ce souci (mon Xcover a rendu l'âme, donc impossible à tester)". Ce qui voulait dire que le seul que je n'avais pas pu tester - car j'ai bien testé -, c'est le Galaxy Xcover (le premier de la série des Xcover). Et où avez-vous lu que je n'en possédais plus ?

    Pour faire bonne mesure, mon panel de test comportait en plus des Xcover's, un Galaxy S5 Active. Les résultats sont les suivants :

    . Galaxy Xcover 2 (Android 4 + TN Android 2.8) : datation correcte

    . Galaxy Xcover 3 (Android 5 + TN Android 3.3.4) : datation erronée

    . Galaxy S5 Active (Android 5 + TN Android 3.3.4) : datation correcte

    . Galaxy Xcover 4 ( (Android 8 + TN Android 3.2.8) : datation correcte

    Conclusion : sur 4 appareils testés avec différentes versions de TwoNav Android, un seul a bugué. Pas de chance, c'est le vôtre, mais ça ne vous autorise nullement à généraliser et à écrire que "Manifestement, le bug existe sur tous les smartphones avec Twonav Android." Ceci est tout aussi faux qu’exagéré.

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    Excusez moi, mon incompréhension vient de ce que je n'avais pas compris que vous aviez une pareille collection de smartphones ;-), je pensais que en disant que votre Xcover avait rendu l'âme, c'était le dernier, et qu'implicitement, les autres n'étaient plus en votre possession.

    Ceci dit, je parlais de la dernière version de Twonav Android, la 3.3.4, il serait intéressant avec les Xcover 2 et 4 de voir ce que cela donne dans ces cas là.

    Bon, pour que vous puissiez me réaccorder votre autorisation, je vais changer ma formulation. Comme, à version égale de Twonav Android (i.e. 3.3.4), cela fonctionne dans certains cas et non d'autres, et que il est prouvé par ailleurs que quand ça bugue sur un matériel, un autre logiciel ne bugue pas avec ce même matériel, je vais me contenter de dire "Twonav Android 3.3.4 ne corrige pas le changement de semaine au 6 avril 2019, ce qui provoque une datation erronée sur certain matériels mais pas sur tous".

    Je maintiens (avec votre autorisation ou pas) qu'une programmation adéquate éviterait (aurait évité) ce problème, et dans mon référentiel, une programmation inadéquate est une source fatale de bug(s). Cette version de Twonav Android est donc buggué, mais le bug ne se manifeste pas sur tous les matériels. 
    Sale temps pour les drosophiles en ce moment... ;-)

    Cordialement,

    0
    Actions pour les commentaires Permalien
  • Avatar
    Jules Savignac

    << je n'avais pas compris que vous aviez une pareille collection de smartphones ;-) >>

    Comme beaucoup de gens de ma génération je pense, j'ai du mal à me débarrasser de quelque chose qui fonctionne encore. Alors, ça s'entasse jusqu'à ce qu'une sainte colère prenne ma femme et qu'elle fasse le tri ! Jusque là, j'ai réussi à préserver les vieux smartphones, et même les Evadeo IGN hors d'âge (qui auraient pu être touché par le bug qui nous occupe mais ne l'ont pas été).

    << je parlais de la dernière version de Twonav Android, la 3.3.4, il serait intéressant avec les Xcover 2 et 4 de voir ce que cela donne dans ces cas là. >>

    Non pour le Xcover 2 car je ne l'ai réactivé que pour le test (c'était le plus ancien que j'avais) et ça m'intéresse de le conserver avec TN 2.8 dessus. Et non pour le Xcover 4 car c'est celui que j'utilise en ce moment et que je ne veux pas mettre dessus TN Android 3.3.4 et son bug de l'extinction intempestive de l'écran.

    << je vais me contenter de dire "Twonav Android 3.3.4 ne corrige pas le changement de semaine au 6 avril 2019, ce qui provoque une datation erronée sur certain matériels mais pas sur tous". >>

    Je suis d'accord avec ça.

    << Je maintiens ( ... ) qu'une programmation adéquate éviterait (aurait évité) ce problème, >>

    Convenez quand même que la tâche de TwoNav n'est pas facile : ça bugue avec TN Android 3.3.4 sous Android 5 sur le Xcover 3 mais pas sur le S5 Active.

    << Cette version de Twonav Android est donc buggué, >>

    Ça, c'est pas un scoop, et certains bugs dont celui de l'extinction intempestive de l'écran touchent tous les smartphones - ou tablettes - Android. Vivement la sortie d'une version de TN Android où les bugs signalés auront, enfin, été corrigés. Oui, je sais, je ne devrais plus croire au Père Noël à mon âge.

     

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    "Convenez quand même que la tâche de TwoNav n'est pas facile"

    Ni plus ni moins que celle de tous les développeurs Android ! Twonav est une application vendues, avec un service derrière (vente de cartes, abonnements), c'est le devoir d'un éditeur de faire que son logiciel fonctionne !

    Et quand je compare (sous Android) Locus à Twonav, y-a pas photo, je sens que je vais migrer...

    "et certains bugs dont celui de l'extinction intempestive de l'écran touchent tous les smartphones - ou tablettes - Android."

    Ah ben non là... jamais eu ça sur mon Xcover 3, ni sur les deux tablettes où je l'ai installé !
    Donc, je ne vous autorise pas... ;-)

    Cordialement,

     

    0
    Actions pour les commentaires Permalien
  • Avatar
    www.twolandnaviste .fr

    Bonjour à tous,

    dans celui que vous indiquez, c'est un "bug du 6 avril" cumulé à un "bug de l'an 2000" (inverse...)

    Bernard, quand j'ai acheté mon Evadéo le bug de l'an 2000 était passé depuis 11 ans...

    Et, SVP, essayez d'expliquer les choses avec des phrases "de tous les jours" (je parle pour mon petit cas). A chaque explication que je vous demande, la réponse est encore plus obscure.

    1999 + 20 + ? = 2099 

    Cordialement

    Laurent

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    "Bernard, quand j'ai acheté mon Evadéo le bug de l'an 2000 était passé depuis 11 ans..."

    Justement... je vais expliciter mieux...

    Le fondement du "bug de l'an 2000", c'est un codage des dates (des années) sur deux digit décimaux : oar exemple, pour coder 1981, on a une variable ou un stockage qui ne contient que "81", et implicitement, lors de l'exploitation (affichage par exemple), on ajoute/ajoutait un "19" devant. Sauf que si la programmation était trop simpliste, lorsqu'on se retrouvait le 1er janvier 2000 avec une année codée "00", on affichait 1900 et non pas 2000. Il fallait anticiper ce passage de siècle dans la programmation, ce qui n'était pas le cas dans toutes les applications.

    Le fondement du "bug du 6 avril", c'est que la date est codée (transmise) par le numéro de semaine, sur 10 bits (décision arbitraire et historique du DoD pour limiter les performances du GPS lorsqu'il a été "civilisé"). En conséquence, lors d'un retour à zéro du compteur, on revient le 22 aout 1999 (c'était le temps "t=0" du protocole), sauf si on a une programmation qui intègre la notion de non réversibilité du temps.

    Dans ce cas (Evadéo), de toute évidence, il est soumis à ce bug WRNO (Week Number Roll Over), donc, l'année devient 1999, mais de plus, il semble avoir aussi une programmation simplifiée de la date en ne prenant en compte que les deux derniers chiffres (soient "99", c'est à dire le fondement du "bug de l'an 2000, mais transposé au 21e siècle), et ajoute arbitrairement un "20" devant pour afficher l'année complète (donc padding de "20" et "99" et non pas "1999+20" comme vous l'écrivez).

    Un truc programmé avec les pieds quoi...

    Est-ce plus clair ?

    Cordialement

    PS : à venir, le bug du codage de temps POSIX, qui va intervenir le 19 janvier 2038, à 3h 14mn et 8s. Le codage des dates sous Unix (donc les kernels de la majorité des OS aujourd'hui, surtout ceux d'infrastructure) est stocké en secondes, en 32 bits, avec début le 1er janvier 1970 à 0h, et retour à zéro ce 19 janv. 2038.

     

    0
    Actions pour les commentaires Permalien
  • Avatar
    Roland Burnet

    Laurent,

    Ce n’est pas 1999 + 20 + ?, mais 99 + 20*100. Seules les années avec leurs dizaines seraient données, et ce sont les centaines et milliers d’années qui sont rajoutées par la suite.

    Bernard.

    "Bref, de la programmation de gougnafier dans tous les cas !"

    Toujours assez choqué par des jugements dégradants envers des personnes, je trouve cette mention tout à fait déplacée. Que l’on donne un avis très négatif sur une entreprise, je le conçois, envers son personnel, pas du tout.

    Ceci d’autant plus que le matériel concerné est de fabrication allemande (Médion) qui incorpore du TwoNav mais adapté au matériel. Donc le "bug du 6 avril" est imputable à la puce GPS utilisée, et le 2099 à l’adaptation de TwoNav dans l’appareil car la date et l’heure d’enregistrement d’un fichier dépendent du SE, Windows CE en l’occurrence, et TwoNav n’a rien à voir là-dedans.

    Cordialement

    R. Burnet

    0
    Actions pour les commentaires Permalien
  • Avatar
    Bernard Perrot

    "Que l’on donne un avis très négatif sur une entreprise, je le conçois, envers son personnel, pas du tout."

    Et pourtant, les erreurs de programmation sont le fait des programmeurs, pas de la structure d'emploi...

    Un très vieux proverbe de l'informatique dit :

    " A toute erreur attribuée à l'ordinateur, il y a au départ deux erreurs humaines, dont celle qui consiste à accuser l'ordinateur ".

    Cordialement,

    0
    Actions pour les commentaires Permalien

Vous devez vous connecter pour laisser un commentaire.