Derniers messages sur Zeste de Savoirhttps://zestedesavoir.com/forums/2022-10-21T23:36:36+02:00Les derniers messages parus sur le forum de Zeste de Savoir.récupération de données, message #2460432022-10-21T23:36:36+02:00SylafrsOne/@SylafrsOnehttps://zestedesavoir.com/forums/sujet/16486/recuperation-de-donnees/?page=1#p246043<p>Je trouve étrange le fait de demander à la fois les données d’étudiant et les données de recruteur ?</p>
<ul>
<li>Si tu dois connecter un utilisateur, qu’importe son role, tu peux demander la table utilisateur</li>
<li>Si tu dois récupérer les données étudiant d’un utilisateur, tu peux faire la jointure avec la table etudiant et si tu dois récupérer les données recruteur, une jointure recruteur</li>
</ul>
<p>Mais j’ai du mal à imaginer une requete pour tout récupérer, à part en faisant un bricolage avec UNION</p>
<hr>
<p>NB: Je n’ai pas fait beaucoup de BDD depuis mes études, faut vraiment pas prendre ma réponse comme argent comptant</p>récupération de données, message #2455272022-09-22T09:41:12+02:00DonKnacki/@DonKnackihttps://zestedesavoir.com/forums/sujet/16486/recuperation-de-donnees/?page=1#p245527<p>Bonjour</p>
<p>Un étudiant a des caractéristiques très différentes d’un recruteur ? </p>récupération de données, message #2455192022-09-21T18:10:36+02:00Drux/@Druxhttps://zestedesavoir.com/forums/sujet/16486/recuperation-de-donnees/?page=1#p245519<p>Bonjour tout le monde,</p>
<p>je viens vers vous pour avoir quelques conseils et orientations sur un problème.</p>
<p>Voici mon problème j’ai dans ma BDD 3 tables ayant un cas d’héritage.</p>
<p>voici les tables:</p>
<ol>
<li>UTILISATEUR (table parent)</li>
<li>ETUDIANT (table enfant)</li>
<li>RECRUTEUR (table enfant)</li>
</ol>
<p>Le contexte est qu’un UTILISATEUR peut-être soit un ETUDIANT soit un RECRUTEUR jamais les deux à la fois.</p>
<p>voici une illustration pour aider votre compréhension:
<a href="http://fpmseta.epizy.com/Sans-titre---1.jpg">Image utilisateur</a></p>
<p>Alors je rencontre un problème lors de l’implémentation de la requête BDD pour connecter soit un ETUDIANT soit un RECRUTEUR, je ne sais pas du tout comment m’y prendre car c’est la première que j’utilise la notion de l’héritage dans ma BDD; mais voici une requêté que j’ai essayé d’écrire, dites-moi si c’est bon ou pas:</p>
<div class="hljs-code-div hljs-code-sql"><div class="hljs-line-numbers"><span data-count="1"></span><span data-count="2"></span><span data-count="3"></span><span data-count="4"></span><span data-count="5"></span></div><pre><code class="hljs language-sql"><span class="hljs-keyword">SELECT</span> UT.<span class="hljs-operator">*</span>, ET.<span class="hljs-operator">*</span>, RE.<span class="hljs-operator">*</span>
<span class="hljs-keyword">FROM</span> utilisateur UT
<span class="hljs-keyword">LEFT</span> <span class="hljs-keyword">JOIN</span> etudiant ET <span class="hljs-keyword">ON</span> ET.id_utilisateur<span class="hljs-operator">=</span>UT.id
<span class="hljs-keyword">LEFT</span> <span class="hljs-keyword">JOIN</span> recruteur RE <span class="hljs-keyword">ON</span> RE.id_utilisateur<span class="hljs-operator">=</span>UT.id
<span class="hljs-keyword">WHERE</span> UT.email<span class="hljs-operator">=</span><span class="hljs-string">'exemple@domaine.tst'</span>
</code></pre></div>
<p>Merci d’avance pour vos réponses.</p>Dates : confusion entre UTC, GMT, Locale, etc., message #2376482021-09-21T10:26:35+02:00Ymox/@Ymoxhttps://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=2#p237648<p>Salut</p>
<p>Sauf erreur, il utilise MySQL qui ne permet pas vraiment d’enregistrer les dates avec le fuseau horaire dans le même champ, donc cela revient probablement à la même chose qu’utiliser <code>datetime</code> dans son cas, et ça ne résout pas vraiment le problème apparemment — sachant que les tests montrent que le souci se pose <em>avant</em> que la base de données soit impliquée.</p>Dates : confusion entre UTC, GMT, Locale, etc., message #2376462021-09-21T09:56:47+02:00Cyberkh/@Cyberkhhttps://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=2#p237646<p>Bonjour,</p>
<p>est-ce que tu est sur du type de données mappée dans ton entité Symfony ?</p>
<p>Personnellement j’utilise datetimetz : <a href="https://www.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/types.html#datetimetz">Lien documentation doctrine</a></p>Dates : confusion entre UTC, GMT, Locale, etc., message #2375892021-09-17T15:46:11+02:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=2#p237589<p>Pour commencer, ton API envoie une date et heure avec fuseau horaire, mais le retour n’a pas de fuseau horaire, pas plus que le le stockage en base. Partant de là, <em>ça ne peut pas</em> fonctionner.</p>
<p>Si tu veux changer de fonctionnement, la première étape est de regarder si ton besoin fonctionnel te permet d’utiliser des instants, ou des dates et heures dépendants de l’utilisateur (donc sans fuseau horaire). Cf mon message à ce sujet plus haut dans la conversation.</p>Dates : confusion entre UTC, GMT, Locale, etc., message #2375872021-09-17T15:35:10+02:00JeanTilapin/@JeanTilapinhttps://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=2#p237587<p>Bon. J’ai passé les jours derniers à avancer sur d’autres points du projet pour me changer les idées, en me donnant le temps de revenir sur cette prise de tête plus tard. Je ne sais pas si je progresse ou régresse sur le sujet :</p>
<ul>
<li>je POST via l’api : </li>
</ul>
<div class="hljs-code-div hljs-code-js"><div class="hljs-line-numbers"><span data-count="1"></span><span data-count="2"></span><span data-count="3"></span><span data-count="4"></span><span data-count="5"></span></div><pre><code class="hljs language-js">{
<span class="hljs-string">"name"</span>: <span class="hljs-string">"jour test 2"</span>,
<span class="hljs-string">"start"</span>: <span class="hljs-string">"2021-09-20T00:00:00.000Z"</span>,
<span class="hljs-string">"end"</span>: <span class="hljs-string">"2021-09-20T23:59:59.000Z"</span>,
}
</code></pre></div>
<p>On me renvoie :</p>
<div class="hljs-code-div hljs-code-js"><div class="hljs-line-numbers"><span data-count="1"></span><span data-count="2"></span><span data-count="3"></span><span data-count="4"></span><span data-count="5"></span><span data-count="6"></span><span data-count="7"></span><span data-count="8"></span><span data-count="9"></span><span data-count="10"></span></div><pre><code class="hljs language-js">{
<span class="hljs-string">"@context"</span>: <span class="hljs-string">"/api/contexts/Vacation"</span>,
<span class="hljs-string">"@id"</span>: <span class="hljs-string">"/api/vacations/88"</span>,
<span class="hljs-string">"@type"</span>: <span class="hljs-string">"Vacation"</span>,
<span class="hljs-string">"id"</span>: <span class="hljs-number">88</span>,
<span class="hljs-string">"name"</span>: <span class="hljs-string">"jour test 2"</span>,
<span class="hljs-string">"start"</span>: <span class="hljs-string">"2021-09-19 22:00"</span>,
<span class="hljs-string">"end"</span>: <span class="hljs-string">"2021-09-20 21:59"</span>,
}
</code></pre></div>
<p>En BDD j’ai <code>88 jour test 2 2021-09-20 00:00:00 2021-09-20 23:59:59</code></p>
<p>Sur le Front-end, par contre, je retrouve les données "-2h", même en utilisant Date.parse() ou toLocaleString().</p>
<hr>
<p>Si je voulais complètement laisser tomber cette norme ISO que je n’arrive pas à faire fonctionner, comment être sûr de mon coup ? Après tout, tout ça concerne des horaires locaux consultés par des locaux.</p>
<ul>
<li>lors de l’envoi, aucun T et Z ?</li>
<li>dans la BDD, des horaires correspondant très exactement à ce que j’ai envoyé ? </li>
<li>toujours dans la BDD, utiliser convert_tz (cf ci-dessus) pour rectifier les 3000+ horaires déjà enregistrés ?</li>
<li>modifier/ou vérifier la configuration de quelque chose dans API Platform/Symfony ?</li>
</ul>
<p>Merci.</p>
<hr>
<p>Edit :
Bon, quand je poste sans les T et Z, le résultat est strictement identique.</p>
<p>Edit 2:
Ah non, <em>my bad</em>, j’avais laissé lors d’un précédent test la configuration dans services.yaml qui stipulait timezone 'UTC’. Si je la commente, l’inscription sans T et Z fonctionne normalement.</p>Dates : confusion entre UTC, GMT, Locale, etc., message #2373962021-09-10T11:45:23+02:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=2#p237396<figure><blockquote>
<p>D’ailleurs, SpaceFox, histoire que je fasse le test correctement : quand tu dis de tester l’insertion de « le 9 septembre 2021 à 21h03 UTC+2 », ce serait comment exactement, avec quel résultat attendu ?</p>
</blockquote><figcaption><a href="https://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=2#p237393">JeanTilapin</a></figcaption></figure>
<p>Je ne connais plus les outils MySQL, mais l’idée c’est d’écrire une requête <code>insert</code> qui enregistre une date avec un fuseau particulier (idéalement ni UTC, ni le fuseau du serveur, pour éviter les coïncidences), et une <code>select</code> qui va la lire, et de vérifier que tu as toujours le bon fuseau dans les informations remontées.</p>
<figure><blockquote>
<p>Histoire d’en avoir le coeur net, je viens de poster un horaire au 25 décembre - donc heure d’hiver en France - et je retrouve en BDD l’heure h-1, toujours en Time Zone +0200. Je ne sais pas si ça fait avancer le schmilblick, par contre <img src="/static/smileys/svg/hihi.svg" alt="^^" class="smiley"></p>
</blockquote><figcaption><a href="https://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=2#p237393">JeanTilapin</a></figcaption></figure>
<p>Ça le fait avancer dans le sens où ça montre que tu as sans doute un problème <em>avant</em> l’insertion en base.</p>Dates : confusion entre UTC, GMT, Locale, etc., message #2373932021-09-10T11:03:57+02:00JeanTilapin/@JeanTilapinhttps://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=2#p237393<p><strong>Concernant la version MySQL</strong></p>
<p>Bon, de mon côté, j’ai vérifié, j’ai bien une version >8 de mysql sur mon environnement de travail. Ca ne marche pas, mais au moins il y a la certitude que ça <em>devrait</em> marcher. </p>
<p>Par contre, je viens de vérifier mon hébergeur actuel (nuxit) qui est en version <7.4. De ce que je vois, OVH est en version 5.6 ou 8, mais ne les ayant pas encore contacté, je ne sais pas si on peut demander à être sur une version 8. </p>
<p>Du coup, si de toute façon mon hébergeur probable ne peut pas me garantir que je serai en 8, au final, cette prise de tête monumentale est peut-être - en plus - inutile ; à part bien sûr pour le plaisir de comprendre l’origine d’un problème et de le résoudre.</p>
<p><strong>Concernant les étapes d’Ymox</strong></p>
<p>Je mettrais volontiers les étapes 1 et 2 hors de cause vu que si je passe par l’interface API elles sont automatiquement zappées et que ça ne change rien. On voit également que les étapes 5/6/7 sont probablement aussi hors de cause puisque les données sont déjà fausses en BDD.
Restent les étapes 3 et 4.
Là, je suis passé en "datetime_timezone: 'UTC’" dans services.yaml (Symfony\Component\Serializer\Normalizer\DateTimeNormalizer:). J’ai bien vidé le cache, refait des tests, et le problème persiste : Doctrine entre en base de données des heures h-2 sans garder l’info "Z". J’entame des recherches plus approfondies sur la désérialisation via API Platform pour voir si il y aurait d’autres méthodes de test.</p>
<p>Pour l’étape 3, je ne suis pas sûr de bien comprendre ce que tu proposes : c’est en lien avec ce que dit SpaceFox dans la page précédente sur MySQL ?</p>
<p>D’ailleurs, SpaceFox, histoire que je fasse le test correctement : quand tu dis de tester l’insertion de « le 9 septembre 2021 à 21h03 UTC+2 », ce serait comment exactement, avec quel résultat attendu ?</p>
<p><strong>EDIT : à propos de la conversion des données (fausses) actuellement stockées</strong></p>
<p>A priori, la fonction convert_tz va me permettre de mettre à jour mes données sans tout perdre. Il va falloir que je regarde de près si l’information du changement d’heure en hiver peut se gérer intelligemment.</p>
<p>En tout cas, <code>SELECT convert_tz(opening_time, '+00:00','+2:00') from opening_hours where activity_id = 36 </code> me renvoie des heures correctes.</p>
<p><strong>EDIT 2 : à propos de l’heure d’hiver</strong></p>
<p>Histoire d’en avoir le coeur net, je viens de poster un horaire au 25 décembre - donc heure d’hiver en France - et je retrouve en BDD l’heure h-1, toujours en Time Zone +0200. Je ne sais pas si ça fait avancer le schmilblick, par contre <img src="/static/smileys/svg/hihi.svg" alt="^^" class="smiley"></p>Dates : confusion entre UTC, GMT, Locale, etc., message #2373902021-09-10T08:44:57+02:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=2#p237390<figure><blockquote>
<p>Il n’y a pas la possibilité de convertir avant en UTC pour l’enregistrer dans la BDD, et de gérer la conversion pour l’affichage selon le client ?</p>
</blockquote><figcaption><a href="https://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=1#p237387">Moté</a></figcaption></figure>
<p>Pas avec le besoin exprimé, qui est de conserver les informations de fuseau horaire.
Ce que tu décris correspond au cas où tu veux gérer des instants, et où tu n’as pas de format de timestamp utilisable dans toute la chaîne : c’est l’heure UTC qui fait office de timestamp. </p>Dates : confusion entre UTC, GMT, Locale, etc., message #2373882021-09-09T23:35:13+02:00Ymox/@Ymoxhttps://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=2#p237388<p>En fait, si je reprends la chaîne, il y a plusieurs maillons : </p>
<ol>
<li>la récupération de la valeur du champ</li>
<li>la sérialisation avant envoi</li>
<li>la dé-sérialisation à la réception</li>
<li>le formatage pour insertion en base</li>
<li>la récupération depuis la base</li>
<li>la sérialisation pour l’envoi</li>
<li>la "reconstruction" à la réception</li>
</ol>
<p>J’aurais déjà envie dans un premier temps de mettre <code>UTC</code> à la place de <code>Europe/Paris</code> dans la configuration du <em>normalizer</em>, vu qu’on sait que c’est envoyé du client formaté avec <code>toISOString()</code> et que du coup c’est de l’UTC. On verra vite ce qu’il en est pour le retour.</p>
<p>Ensuite, je ne sais pas si les données envoyées sont celles reprises depuis la BDD (donc on aurait les étapes 4, 5 et 6) ou si c’est simplement celles reprises directement après l’étape 3, ce qui permettrait de cibler une partie du problème.</p>Dates : confusion entre UTC, GMT, Locale, etc., message #2373872021-09-09T22:25:18+02:00Moté/@Mot%C3%A9https://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=1#p237387<p>Il n’y a pas la possibilité de convertir avant en UTC pour l’enregistrer dans la BDD, et de gérer la conversion pour l’affichage selon le client ?</p>Dates : confusion entre UTC, GMT, Locale, etc., message #2373862021-09-09T21:13:07+02:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=1#p237386<p>OK, alors la première chose à faire, c’est de vérifier que tu as une version de MySQL supérieure à la 8.0.19, sans quoi tu ne pourras pas gérer correctement les fuseaux horaires :</p>
<figure><blockquote>
<p>Beginning with MySQL 8.0.19, you can specify a time zone offset when inserting TIMESTAMP and DATETIME values into a table. The offset is appended to the time part of a datetime literal, with no intravening spaces, and uses the same format used for setting the time_zone system variable, with the following exceptions: […]</p>
</blockquote><figcaption><a href="https://dev.mysql.com/doc/refman/8.0/en/date-and-time-literals.html">La doc de MySQL 8</a></figcaption></figure>
<p>Partant de là, tu peux déjà vérifier que quand tu rentres « le 9 septembre 2021 à 21h03 UTC+2 » dans la base, il enregistre bien <em>exactement ça</em> et pas <a href="https://dev.mysql.com/doc/refman/8.0/en/datetime.html">une conversion bizarre ou une version tronquée</a>. Ça implique d’avoir la bonne version de MySQL <em>et</em> le bon type de colonne de stockage.</p>
<p>Ensuite, il faut fouiller dans la doc de tes outils (Doctrine et Vue au moins) pour vérifier que les types et méthodes de conversion que tu utilises comprennent bien cette histoire de fuseau horaire <strong>sans faire de conversion ni ignorer le fuseau</strong>, parce que parfois on a des surprises – surtout avec les bindings de BDD, qui sont historiquement assez lents à suivre les nouveautés d’un côté ou de l’autre.</p>
<p>Si <em>toute la chaine</em> est compatible, tu es bon.</p>
<p>Si tu as un trou dans la raquette (typiquement une conversion sauvage ou les informations de fuseau horaire ignorées), tu as plusieurs possibilités, et là il n’y a que la connaissance du fonctionnel qui permettra de répondre :</p>
<ul>
<li>La technique ancienne avec MySQL qui consiste à ajouter une colonne par date pour stocker le fuseau horaire (mais les comparaisons de dates en SQL ne fonctionneront plus correctement si le fuseau est différent).</li>
<li>Considérer que tu peux en fait gérer des <em>instants</em> (les instants d’ouverture et de fermeture d’après tes exemples), qui sont gérés intégralement avec des <em>timestamp</em> avec conversion à l’affichage le plus tard possible (convertis en date selon le fuseau horaire de ton utilisateur, ou de l’entité qui ouvre/ferme selon ce que tu veux afficher).</li>
<li>Considérer que tu peux en fait gérer des <em>dates dépendantes de l’utilisateur</em> (les dates et heures d’ouverture et de fermeture, <em>dans le fuseau horaire local de l’entité concernée</em>), avec l’information du fuseau horaire stockée avec l’entité (et pas avec les dates) et affichée séparément.</li>
</ul>
<p>Le choix entre tout ça va énormément dépendre des calculs et comparaisons que tu vas vouloir faire sur tes dates.</p>Dates : confusion entre UTC, GMT, Locale, etc., message #2373732021-09-09T13:38:55+02:00JeanTilapin/@JeanTilapinhttps://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=1#p237373<p>Je vous jure que j’essaye réellement de comprendre, hein (ce n’est peut-être pas évident pour vous). Merci réellement de m’aider sur ce coup.</p>
<p>Pour répondre à SpaceFox, le type de date qui m’intéresse, selon le tuto, serait la date locale dépendante de l’utilisateur : je stocke des horaires d’activités qui ont lieu en France dans des plages horaires précises et qui exigent que l’utilisateur soit dans la même zone géographique pour en profiter (référentiel implicite ?). Savoir que ça correspond à 4h du matin en Indonésie n’apporte rien.</p>
<p>Edit : grâce à la remarque d’Ymox précédente qui souligne que dès l’introduction en BDD ça foire, je regarde le log via le Symfony Profiler et dans Doctrine je découvre pour un test réalisé à 14:33 :</p>
<div class="hljs-code-div hljs-code-php"><div class="hljs-line-numbers"><span data-count="1"></span><span data-count="2"></span><span data-count="3"></span><span data-count="4"></span><span data-count="5"></span><span data-count="6"></span><span data-count="7"></span><span data-count="8"></span><span data-count="9"></span><span data-count="10"></span></div><pre><code class="hljs language-php">INSERT INTO opening_hours (day, opening_time, closing_time, activity_id) VALUES (?, ?, ?, ?)
Parameters:
[▼
<span class="hljs-number">1</span> => <span class="hljs-string">"2021-09-09"</span>
<span class="hljs-number">2</span> => <span class="hljs-string">"2021-09-09 12:33:52"</span>
<span class="hljs-number">3</span> => <span class="hljs-string">"2021-09-09 12:33:52"</span>
<span class="hljs-number">4</span> => <span class="hljs-number">36</span>
]
</code></pre></div>
<p>Est-ce que ça aide d’une manière ou d’une autre à comprendre d’où vient mon problème ? Doctrine ? Symfony ? PHP sur mon PC ? API Platform ?</p>
<p>Edit 2 :
En entrant juste sans les T / Z :</p>
<div class="hljs-code-div hljs-code-js"><div class="hljs-line-numbers"><span data-count="1"></span><span data-count="2"></span><span data-count="3"></span><span data-count="4"></span><span data-count="5"></span><span data-count="6"></span></div><pre><code class="hljs language-js">{
<span class="hljs-string">"day"</span>: <span class="hljs-string">"2021-09-09"</span>,
<span class="hljs-string">"openingTime"</span>: <span class="hljs-string">"2021-09-09 14:42:35.354"</span>,
<span class="hljs-string">"closingTime"</span>: <span class="hljs-string">"2021-09-09 14:42:35.354"</span>,
<span class="hljs-string">"activity"</span>: <span class="hljs-string">"/api/activities/36"</span>
}
</code></pre></div>
<p>j’ai l’enregistrement correct en BDD. </p>
<p>Devant ma totale incompréhension du problème et de son origine, ne vaut-il pas mieux que je laisse complètement tomber cette histoire de toISOString() et de UTC, et que je formate les données entrées par l’utilisateur sans aucune info de ce type ?</p>
<p>Question subsidiaire : a priori, tous mes enregistrements actuels en BDD sont faux, donc. Y a-t-il moyen de les corriger sans devoir tout re-rentrer ? </p>Dates : confusion entre UTC, GMT, Locale, etc., message #2373702021-09-09T12:36:09+02:00Ymox/@Ymoxhttps://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=1#p237370<p>Première étape : non, le retour possède déjà le mauvais fuseau horaire, ce qui est envoyé n’est pas la même chose que ce qui est retourné. Attention, c’est justement le point du tutoriel qui t’a été proposé : <code>2021-09-09T09:57:49.273Z</code> n’est pas la même chose que <code>2021-09-09T09:57:49.273+02:00</code>, parce que cette dernière équivaut à <code>2021-09-09T07:57:49.273Z</code>.</p>
<p>Deuxième étape : là, difficile de savoir. Il faudrait enregistrer des dates à l’heure d’été et des dates à l’heure d’hiver pour savoir si le décalage en base est toujours le même ou s’il s’adapte.</p>
<p>Troisième étape : non, du fait du souci de la première étape.</p>
<p>Quatrième étape (point 5) , je m’étais trompé : pour reconstruire une date en JavaScript, il faut faire <code>new Date(Date.parse( la chaîne au format ISO ))</code>. Le constructeur de l’objet Date en JavaScript ne prend qu’un entier, et cela explique en partie le souci sur cet exemple de code. Quand bien même, le <code>+02:00</code> apparaît comme ignoré parce que c’est le fuseau horaire local par défaut de ton navigateur.</p>Dates : confusion entre UTC, GMT, Locale, etc., message #2373692021-09-09T12:35:40+02:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=1#p237369<p>Première question pour pouvoir t’aider, parce que j’ai l’impression en te lisant que le problème vient de là : <a href="https://zestedesavoir.com/contenus/beta/3843/dates-durees-et-horloges-en-informatique/les-dates-et-heures/#1-les-3-trois-types-de-dates">quel type de « date » tu as besoin de gérer</a> ? (d’un point de vue purement fonctionnel, en ignorant tout ce qui existe côté technique).</p>Dates : confusion entre UTC, GMT, Locale, etc., message #2373672021-09-09T12:14:06+02:00JeanTilapin/@JeanTilapinhttps://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=1#p237367<p>Bon.
Il vaut mieux se rendre compte maintenant du souci que lors de la mise en production, hein. Mais vous n’imaginez pas à quel point je suis énervé. Je reprends donc calmement. <em>respire à fond</em></p>
<p>Via les api/docs (donc sans mon interface JS/Vue qui pourrait être la cause de mon souci) :</p>
<p>1- les horaires sont automatiques quand on clique sur try it out ; je POST ceci à 11h57 (depuis la France) :</p>
<div class="hljs-code-div hljs-code-js"><div class="hljs-line-numbers"><span data-count="1"></span><span data-count="2"></span><span data-count="3"></span><span data-count="4"></span><span data-count="5"></span><span data-count="6"></span></div><pre><code class="hljs language-js">{
<span class="hljs-string">"day"</span>: <span class="hljs-string">"2021-09-09T09:57:49.273Z"</span>,
<span class="hljs-string">"openingTime"</span>: <span class="hljs-string">"2021-09-09T09:57:49.273Z"</span>,
<span class="hljs-string">"closingTime"</span>: <span class="hljs-string">"2021-09-09T09:57:49.273Z"</span>,
<span class="hljs-string">"activity"</span>: <span class="hljs-string">"/api/activities/36"</span>
}
</code></pre></div>
<p>2- j’ai comme Response Body :</p>
<div class="hljs-code-div hljs-code-js"><div class="hljs-line-numbers"><span data-count="1"></span><span data-count="2"></span><span data-count="3"></span><span data-count="4"></span><span data-count="5"></span><span data-count="6"></span><span data-count="7"></span><span data-count="8"></span><span data-count="9"></span><span data-count="10"></span><span data-count="11"></span></div><pre><code class="hljs language-js">{
<span class="hljs-string">"@context"</span>: <span class="hljs-string">"/api/contexts/OpeningHours"</span>,
<span class="hljs-string">"@id"</span>: <span class="hljs-string">"/api/opening_hours/2928"</span>,
<span class="hljs-string">"@type"</span>: <span class="hljs-string">"OpeningHours"</span>,
<span class="hljs-string">"id"</span>: <span class="hljs-number">2928</span>,
<span class="hljs-string">"day"</span>: <span class="hljs-string">"2021-09-09T00:00:00+02:00"</span>,
<span class="hljs-string">"openingTime"</span>: <span class="hljs-string">"2021-09-09T09:57:49+02:00"</span>,
<span class="hljs-string">"closingTime"</span>: <span class="hljs-string">"2021-09-09T09:57:49+02:00"</span>,
<span class="hljs-string">"activity"</span>: <span class="hljs-string">"/api/activities/36"</span>
}
</code></pre></div>
<p>Première étape : est-ce que tout est normal à ce point ?</p>
<p>3- je vais voir sur phpmyadmin le résultat dans la table ; j’ai :</p>
<p><code>2928 36 2021-09-09 2021-09-09 09:57:49 2021-09-09 09:57:49</code></p>
<p>Ici : quand je clique pour éditer les deux derniers champs, j’ai "Time zone+0200" ; je précise que la configuration de mysql est celle par défaut, je n’ai jamais mis les doigts là-dedans.</p>
<p>Seconde étape : là encore, est-ce normal ?</p>
<p>4- Maintenant, je GET cette même ligne toujours via Api/Docs ; j’obtiens : </p>
<div class="hljs-code-div hljs-code-js"><div class="hljs-line-numbers"><span data-count="1"></span><span data-count="2"></span><span data-count="3"></span><span data-count="4"></span><span data-count="5"></span><span data-count="6"></span><span data-count="7"></span><span data-count="8"></span><span data-count="9"></span><span data-count="10"></span></div><pre><code class="hljs language-js">{
<span class="hljs-string">"@context"</span>: <span class="hljs-string">"/api/contexts/OpeningHours"</span>,
<span class="hljs-string">"@id"</span>: <span class="hljs-string">"/api/opening_hours/2928"</span>,
<span class="hljs-string">"@type"</span>: <span class="hljs-string">"OpeningHours"</span>,
<span class="hljs-string">"id"</span>: <span class="hljs-number">2928</span>,
<span class="hljs-string">"day"</span>: <span class="hljs-string">"2021-09-09T00:00:00+02:00"</span>,
<span class="hljs-string">"openingTime"</span>: <span class="hljs-string">"2021-09-09T09:57:49+02:00"</span>,
<span class="hljs-string">"closingTime"</span>: <span class="hljs-string">"2021-09-09T09:57:49+02:00"</span>,
<span class="hljs-string">"activity"</span>: <span class="hljs-string">"/api/activities/36"</span>
}
</code></pre></div>
<p>Là, on dirait bien que l’info est correctement conservée, non ? Il y a juste le "Z" initial transformé en "+02:00".</p>
<p>5- Maintenant, je veux donc afficher pour un humain normal de nouveau 11h57 depuis "2021–09–09T09:57:49+02:00" ; je fais donc :</p>
<div class="hljs-code-div hljs-code-js"><div class="hljs-line-numbers"><span data-count="1"></span><span data-count="2"></span><span data-count="3"></span><span data-count="4"></span><span data-count="5"></span></div><pre><code class="hljs language-js"><span class="hljs-built_in">console</span>.log(<span class="hljs-keyword">new</span> <span class="hljs-built_in">Date</span>(<span class="hljs-string">"2021-09-09T09:57:49+02:00"</span>))
<span class="hljs-comment">//Date Thu Sep 09 2021 09:57:49 GMT+0200 (heure d’été d’Europe centrale)</span>
<span class="hljs-built_in">console</span>.log(<span class="hljs-keyword">new</span> <span class="hljs-built_in">Date</span>(<span class="hljs-string">"2021-09-09T09:57:49+02:00"</span>).toLocaleString())
<span class="hljs-comment">//09/09/2021, 09:57:49</span>
</code></pre></div>
<p>Et là, je n’ai pas le bon résultat. Comme si le "+02:00" était ignoré. Et si je le remplace par Z, je retrouve le bon 11h57.</p>
<p>Je ne comprends pas ce que je fais de travers.</p>
<p>Merci.</p>Dates : confusion entre UTC, GMT, Locale, etc., message #2373662021-09-09T11:45:13+02:00Ymox/@Ymoxhttps://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=1#p237366<p>Alors vu ce que tu fournis, effectivement il y a déjà un souci à ce niveau apparemment.</p>Dates : confusion entre UTC, GMT, Locale, etc., message #2373652021-09-09T10:34:46+02:00JeanTilapin/@JeanTilapinhttps://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=1#p237365<p>Je réalise seulement maintenant :</p>
<p>Quand mon utilisateur - se trouvant en France - entre des horaires via l’UI de 8h du matin à midi pour le 24 septembre, le script utilise la fonction "toISOString()" et renvoie "2021–09–24T06:00:00+02:00" / 2021–09–24T10:00:00+02:00" -> cette information est incorrecte, c’est bien ça ? Ca devrait être "2021–09–24T08:00:00+02:00 / 2021–09–24T12:00:00+02:00" ?</p>
<p>C’est à ce moment que se crée le décalage qui fait tout foirer ?</p>Dates : confusion entre UTC, GMT, Locale, etc., message #2373612021-09-08T23:22:27+02:00Ymox/@Ymoxhttps://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=1#p237361<p>MySQL n’enregistre rien du fuseau horaire, pour le moins avec les versions 5, je n’ai pas pratiqué la version 8. Mais si tu n’es pas avec MySQL, c’est peut-être différent.</p>
<p>Par contre, <a href="https://www.doctrine-project.org/projects/doctrine-orm/en/2.9/cookbook/working-with-datetime.html#default-timezone-gotcha">Doctrine met en garde sur les histoires de fuseaux horaires</a>. Le souci étant là que la date enregistrée est probablement la bonne au niveau de l’intention, mais quand il y a récupération, c’est le fuseau horaire par défaut qui est pris, mais évidemment sans faire la correction parce que Doctrine n’a aucune idée de comment la faire ni même s’il faut la faire.</p>Dates : confusion entre UTC, GMT, Locale, etc., message #2373522021-09-08T18:33:21+02:00JeanTilapin/@JeanTilapinhttps://zestedesavoir.com/forums/sujet/15673/dates-confusion-entre-utc-gmt-locale-etc/?page=1#p237352<p>Donc c’est sur Symfony que j’ai loupé quelque chose ? Ou Api Platform ? Il y avait un endroit où je devais dire spécifiquement de respecter les données entrées ? Je n’avais jamais eu ce souci avant (c’est mon premier projet avec API Platform), du coup il ne m’était pas venu à l’esprit qu’un problème pourrait survenir de là.</p>
<p>En BDD, ce sont des champs "datetime" (* <a href="/@ORM" rel="nofollow" class="ping ping-link">@<span class="ping-username">ORM</span></a>\Column(type="datetime", nullable=true)). Comment savoir si ma BDD permet de "spécifier le fuseau horaire" ou non ?</p>
<p>Edit : argh, je ne comprends vraiment pas ! Je fais des tests, je crée des horaires : ils sont sous la forme ""2021–09–09T07:00:00.000Z"" lors de l’envoi (9h00 entrés via l’UI) ; dans ma BDD ils apparaissent comme "2021–09–10 07:00:00" ; quand je double-clique sur la case pour éditer l’horaire, j’ai bien dans le panneau qui apparait "Time Zone +0200". C’est donc bien que l’information est enregistrée quelque part, non ?</p>