oui, de meilleures options pour cela devraient être ajoutées. Je ne sais pas quel est le meilleur moyen, je pense qu'il pourrait même y avoir un PR pour cela qui a été soumis il y a longtemps et que je n'ai pas encore eu le temps d'examiner.

Cool merci!
Maintenant, j'ai reconstruit grafana avec le format européen codé en dur dans mon projet =)

Cela serait utile car le format de date européen n'est pas dans le même ordre (jour/mois/année) les dates sont en fait déroutantes

+1

+1

+1

Pour toute autre personne qui souhaite résoudre ce problème ;
Je l'utilise pour ma construction Solaris.

Essaie public_gen si grunt a déjà été exécuté.

``` r, engine='bash', count_lines

!/bin/bash

définir -e

pièce(){
echo -e "Tentative de patch dans;n$GRAPHJSFOLDER"
ORIG=$FOLDER GRAPHJ/graph.js
BACKUP=$GRAPHJSFOLDER/graph.js.backup
cp $ORIG $BACKUP
sed 's/%m\/%d/%d\/%m/g' $BACKUP > $ORIG
}

GRAFANAROOT=$GOPATH/src/github.com/grafana/grafana

GRAPHJSFOLDER=$GRAFANAROOT/public/app/panels/graph
pièce
GRAPHJSFOLDER=$GRAFANAROOT/public_gen/app/panels/graph
pièce
```

+1

+1

+1 à ce sujet, forcer la locale américaine MM/dd dans les graphiques n'est pas idéal. Peut-être aidé par les paramètres régionaux introduits avec #5517 ?

+1

+1, cela bloque actuellement l'adaptation dans notre entreprise

@tokudan Hé, c'est ce que nous avons fait dans notre solution ; https://github.com/grafana/grafana/issues/1459#issuecomment-162446127

Ce serait merveilleux si cela pouvait prendre en compte la localisation réelle du navigateur ou si les utilisateurs pouvaient au moins le configurer manuellement. Forcer tout le monde à utiliser des dates de style américain est vraiment sous-optimal.

+1

+1

Ce serait formidable quand la date pourrait être généralement personnalisée. Exemple:
Au lieu d'avoir
2016-11-21 21:19:00
J'aimerais voir le jour de la semaine ainsi qu'une date courte (format allemand ici) :
Lu, 21.11., 21:19

@RyanCarrier une idée de comment faire cette modification sans construire à partir de la source ? J'ai trouvé le fichier équivalent dans mon installation Ubuntu (à partir du package deb) ici :

/usr/share/grafana/public/app/plugins/panel/graph/graph.ts

Hélas, la modification de ce fichier, le redémarrage de grafana-server et l'actualisation du navigateur ne prennent pas en compte la modification. J'ai repéré cette version minifiée :

/usr/share/grafana/public/app/plugins/panel/graph/graph.js

et je pensais que j'étais sur un gagnant, mais hélas, même résultat. Savez-vous s'il existe une autre sortie de compilation utilisée par grafana qui expliquerait pourquoi la modification de ces fichiers ne fait aucune différence ?

Hé mec, si le script que j'ai écrit précédemment ne fonctionne pas et que vous rencontrez toujours des problèmes, répondez et je regarderai quand j'aurai un peu de temps de retour à la maison (probablement le 2 ou le 3).

https://github.com/grafana/grafana/issues/1459#issuecomment-162446127

Oh désolé, je n'avais pas réalisé à partir du paquet deb. Je vais devoir jeter un œil à la maison et essayer mon serveur. Bouge-moi si je ne réponds pas avant le 3e. :)

Bumping @RyanCarrier -

ils ont changé de truc depuis que j'ai joué pour la dernière fois, et je n'ai pas un environnement comme j'en avais à l'époque. Mais j'ai trouvé %m/%d dans quelques fichiers ; pour vous tenir au courant.

public/app/app_bundle.js:13
public/app/boot.js:18
public/app/boot.fnsdmjkfnasjk.js
le reste est dans
public/app/plugins/panel/graph

graph.ts
graph.js
specs/graph_specs.js
specs/graph_specs.ts

Hé, c'est l'étrange boot.123456.js dans /usr/share/grafana/public/app.

Juste pour être sûr, je le changerais aussi dans boot.js, je suppose qu'il est construit lorsque vous l'installez?

exécutez simplement la commande sed que j'ai créée, rappelez-vous simplement que vos chiffres seront différents mais ;

cp boot.123456.js boot.123456.backup.js
sed 's/%m\/%d/%d\/%m/g' boot.123456.backup.js > boot.123456.js 

puis actualisez simplement la page (ctrl shift r) probs fonctionne avec une actualisation régulière. Mais peu importe.

Désolé, ça m'a pris tellement de temps que j'ai complètement oublié.

la commande remplace simplement tous les %m/%d par %d/%m

Je l'exécuterais également sur les autres fichiers, au cas où ils seraient réunis lors de la recompilation ou de la mise à jour ou quelque chose du genre.

Cela l'a fait ! Un rafraîchissement régulier était suffisant. Les autres fichiers que vous mentionnez sont également présents et contiennent la chaîne.

Un peu mystérieux. Je suppose que cela va être une connaissance utile pour d'autres problèmes qui surgissent. Merci beaucoup!

Existe-t-il un moyen de modifier le format de la date via l'interface graphique ou les paramètres de Grafana ? Je peux voir des discussions sur la modification des fichiers source, ce que je préfère ne pas faire :)

@leinad13 Pas pour le moment, d'où le recours aux fichiers sources. Pas idéal, mais en fait assez facile.

Cela devrait le faire, exécuté à partir de la ligne de commande sur votre serveur :

TARGET_FILE=`ls /usr/share/grafana/public/app/boot.*.js`
cp $TARGET_FILE ${TARGET_FILE}.backup
sed 's/%m\/%d/%d\/%m/g' ${TARGET_FILE}.backup > ${TARGET_FILE}

Ensuite, actualisez simplement la page Grafana de votre navigateur.

+1 aussi pour moi

D'accord, je suis tombé sur cela en comparant Grafana à Kibana. Malheureusement, ne pas prendre en charge les paramètres régionaux (formats date / heure / nombre, etc.) Ce serait vraiment bien si cela était corrigé avec Prio (et sans patch source désagréable). @torkelo

+1

+1

+1

Dans mon cas, j'ai des problèmes avec les dates sur l'axe X qui n'affichent parfois qu'une partie du temps, parfois avec la date (format US, UE ici) et je ne peux pas le contrôler de manière prévisible. En quelque sorte lié à #3591

+1

+1

+1

Au deuxième coup d'œil, le code flot (jquery) est utilisé. Là, vous avez des options de formatage, si elles sont transmises. Voir jquery.flot.time.js
Pour une utilisation mondiale, une bonne localisation est cruciale. Et s'il vous plaît ne vous en tenez pas aux options prises automatiquement dans les paramètres du navigateur. L'utilisation d'une langue basée aux États-Unis ne signifie pas que je souhaite avoir la localisation américaine non conforme...

+1

+1, comme solution de contournement, j'utilise maintenant les vues 23h pour désactiver l'affichage de dates étranges dans les principaux cas d'utilisation.

+1

+1

Nous serions très reconnaissants si vous accordiez la priorité à ce problème. C'est vraiment déroutant pour les utilisateurs européens. Merci beaucoup!

+1

+1

+1

+1

Je ne peux pas déployer cela au Royaume-Uni avec les formats de date américains, car les gens sont assurés de mal lire la date.

Juste pour être clair à ce sujet - les États-Unis sont fondamentalement le seul pays de la planète qui utilise le format de date M/D/Y. Le reste du monde trouve ce format très déroutant. Voir https://en.wikipedia.org/wiki/Date_format_by_country

En ne prenant pas en charge les formats de date locaux, vous dites à quiconque en dehors des États-Unis qu'il ne devrait pas utiliser Grafana.

Utilisez au moins, disons, ISO 8601 par défaut s'il ne peut pas être rendu configurable. Cela devrait être une solution simple qui peut être déployée immédiatement.

Je n'arrive pas à croire que ce bogue ait été signalé il y a trois ans.

Oui, ISO 8601 est une bonne solution à court terme.

Il ne semble pas que Grafana ait le désir ou l'appétit de le faire, je n'avais pas remarqué à l'origine que ce billet avait été créé il y a 3 ans !

ce n'est pas comme si nous ne le voulions pas, mais à moins que vous ne l'ayez pas remarqué, il y a environ 1000 demandes de fonctionnalités ouvertes :)

J'espère que vous vous rendez compte que c'est plus qu'un FR. Il s'agit d'un bloqueur pour l'adoption en dehors des États-Unis. Cela semble être une décision de codage il y a longtemps qui a maintenant des effets secondaires désagréables.

Je vous ai donné des solutions de contournement deux fois plus tôt dans ce fil. Si vous, c'est vraiment un problème pour vous et vous ne pouvez pas contourner le problème pour une raison quelconque. Faites le changement vous-même. Tout l'intérêt de l'open source est de pouvoir contribuer et travailler ensemble, pas de pleurer que ces volontaires ne font pas exactement ce que vous voulez.

@RyanCarrier Nous sommes tous désolés de vous avoir éloigné de vos tâches très importantes. Nous sommes également désolés d'avoir poussé notre fonctionnalité préférée par rapport à ces milliers d'autres FR.
Nous allons probablement commencer à pleurer aux portes de l'Entreprise derrière Grafana à partir de maintenant : https://grafana.com/services/support

Tout d'abord, c'est une toute petite chose. Cela n'est perceptible que si vous effectuez un zoom arrière et si vous survolez un point, vous pouvez voir la date entière. Je ne comprends pas l'argument selon lequel il s'agit d'un bloqueur pour l'adoption en dehors des États-Unis. (J'ai utilisé Grafana depuis le premier jour et je vis en Suède et je n'ai même jamais remarqué ce problème).

En fait, j'ai jeté un coup d'œil à cela la semaine dernière, mais c'était plus compliqué que je ne le pensais. J'ai fait un pic rapide pour essayer de déterminer automatiquement le format mois-jour par paramètre régional - à la fois avec MomentJS et avec Date.prototype.toLocaleDateString() .

MomentJS ne prend pas en charge le format mois/jour par paramètre régional, mais toLocaleDateString peut fonctionner. Le problème est que cela dépend des paramètres de votre navigateur (paramètres de langue dans Chrome) de sorte que la plupart des gens obtiendront de toute façon le format américain même s'ils se trouvent en Europe.

Nous sommes arrivés à la conclusion que la seule façon de le faire serait de l'ajouter en tant que paramètre de configuration (avec des choix : utiliser les paramètres régionaux du navigateur ou définir explicitement).

PS @mvhconsult Grafana est un projet open source et la plupart des versions consistent principalement en des fonctionnalités et des corrections de bogues apportées par la communauté Grafana. Vous ne payez rien pour Grafana et n'avez jamais apporté de correctifs ou de fonctionnalités, alors essayez de garder le ton civil.

@daniellee Avec le risque de lancer une vraie discussion hors sujet ici, donc c'est la dernière de ma part. Je suis impliqué dans l'opensource depuis 15 ans, donc je sais ce que c'est que de recevoir toutes ces demandes qui vous semblent sans importance. Bien sûr, la plupart n'est pas visible ici.
Une façon d'impliquer les gens et de passer leur temps précieux à se pencher sur un autre projet (il y a une vie en dehors de Grafana), est de leur donner des indications sur la façon de travailler et les raisons pour lesquelles les choses ne sont pas prises en compte par l'équipe de base, ainsi que code documenté. Le moyen d'effrayer les gens (ou même de leur faire dire "pourquoi me soucierais-je encore de ce produit ou de cette équipe") est de leur dire que c'est un non-sens, ils devraient simplement creuser dans le code source et implémenter eux-mêmes des correctifs à mi-chemin, et les rabaisser en leur disant qu'ils gémissent/pleurent. Si la politique ici est que seuls les contributeurs de code peuvent faire des demandes : d'accord avec moi, alors je reviens à la vraie vie.

@mvhconsult personne de l'équipe principale n'a dit que cette demande de fonctionnalité était absurde. Je fais partie de l'équipe de base et j'ai passé du temps à chercher comment le résoudre. Peut-être n'avez-vous pas remarqué que je me suis récemment attribué ce problème ? Je voulais aussi juste souligner qu'il s'agit d'un petit problème et non de quelque chose que nous marquerions comme priorité 1 (c'est absolument un problème valide mais il n'affecte pas la plupart des gens et même les personnes qui le remarquent peuvent facilement le contourner).

La discussion autour des demandes de fonctionnalités est acceptable (et encouragée), mais j'ai estimé que cela n'était pas nécessaire :

Nous allons probablement commencer à pleurer aux portes de la Compagnie derrière Grafana à partir de maintenant :

c'est pourquoi j'ai demandé si vous pouviez l'atténuer un peu. Merci.

Si vous voulez vous lancer, je suis plus qu'heureux de vous aider à démarrer. Vous pouvez commencer par configurer Grafana pour le développement : http://docs.grafana.org/project/building_from_source/

@daniellee ce n'est certainement PAS une petite chose et il n'y a pas de "solution de contournement facile" pour autant que je sache.

Il est extrêmement courant d'avoir des graphiques montrant plus d'un seul jour de données, par exemple la semaine, le mois ou l'année précédente, et tous ces graphiques affichent des dates au format MM/JJ sur l'axe. Vous n'avez pas besoin de passer la souris sur quoi que ce soit pour voir ces dates mal formatées.

Il semble que vous ne rencontriez pas le problème vous-même, mais le nombre de "+1" sur ce fil montre certainement clairement que de nombreuses personnes ont un problème avec cela.

Je pense que la plupart des gens apprécient également les difficultés d'exécuter un projet open source populaire, surtout lorsqu'il y a beaucoup de demandes de fonctionnalités et des ressources minimales. C'est exactement la raison pour laquelle certains d'entre nous défendent ce problème - nous essayons de faire valoir qu'il s'agit d'un gros problème pour BEAUCOUP de personnes, et ce serait formidable si cela pouvait être résolu.

@andymadge cool, je peux comprendre que d'autres puissent avoir un point de vue totalement différent de moi et comme vous le dites, beaucoup de gens ont voté pour. Cette fonctionnalité sera bientôt implémentée car le formatage des coches est erroné dans la plupart des pays et devrait être corrigé.

J'essaie juste de trouver la façon la plus conviviale de présenter cette option. Je pense que je vais changer le format de coche par défaut en toLocaleDateString() avec la première langue en navigator.languages mais j'ai une option de configuration pour définir le format mois/jour (ou jour/mois) dans les préférences de l'utilisateur.

J'ai une question à laquelle peut-être quelqu'un d'un pays avec un format de date qui inclut des points ou similaire (Finlande, Allemagne ou Corée du Sud par exemple) peut répondre.

Est-il correct d'avoir simplement deux options explicites : mm/dd ou dd/mm . Le 20 octobre serait 10/20 ou 20/10 .

@daniellee me semble bien.

Ai-je raison de dire que les coches n'affichent que le mois et le jour, ou l'année et le mois, jamais les 3 ensemble ?

@andymadge oui, tu as raison. Il existe différents formats pour les différents niveaux de zoom. En commençant par le plus dézoomé :

• aaaa/mm
• mm/jj
• mm/jj H:M
• H:M
• H:M:S

Ceux que je vais changer sont mm/dd et mm/dd H:M.

@daniellee Pour les utilisateurs finlandais (et allemands), le format correct serait dd.mm. . dd/mm yyyy est parfois utilisé par des personnes âgées d'origine suédoise, mais le simple dd/mm n'est pas clair dans ce contexte car il n'y a aucun moyen de voir dans quel ordre le jour et le mois sont là. L'utilisation de dd/mm serait encore bien meilleure que l'état actuel si la localisation complète n'est pas facilement disponible.

@calmjm merci - cela a répondu à ma question. Je vais ajouter une troisième option. Il y a peut-être d'autres formats pour d'autres pays mais je pense que 3 est un bon début et couvre beaucoup de pays.

La raison de l'utilisation du format mois/jour (ou jour/mois) légèrement étrange est d'économiser de l'espace. J'ai expérimenté l'utilisation de mmm-dd (12 février) mais cela prend trop de place dans des panneaux de plus petite taille.

L'implémentation consistera à introduire un paramètre par utilisateur, avec 4 options : navigateur, mm/dd , dd/mm et dd.mm. par défaut consiste à utiliser les paramètres régionaux de votre navigateur (basé sur le première langue du navigateur à partir de vos paramètres).

Une autre option potentielle est dd.mm (sans le point à la fin) qui est le format pour des pays comme la Pologne et l'Ukraine.

@daniellee cela semble être une bonne voie à suivre.

@daniellee Je

Aussi, juste un commentaire secondaire. Pour nous, le délimiteur correct entre les minutes et les heures est aussi le point. Mais je ne pense pas qu'il y ait beaucoup de demandes pour changer cela, car il n'est alors pas si facile de voir si "02.02" est l'heure ou la date (c'est l'heure, le point de fin manquant le révèle). Bien sûr, ce serait mieux s'il pouvait également être configuré.

+1

@hraftery

Cela devrait le faire, exécuté à partir de la ligne de commande sur votre serveur : TARGET_FILE= ls /usr/share/grafana/public/app/boot.*.js
cp $TARGET_FILE ${TARGET_FILE}.backup sed 's/%m\/%d/%d\/%m/g' ${TARGET_FILE}.backup > ${TARGET_FILE}
Ensuite, actualisez simplement la page Grafana de votre navigateur.

Je n'ai pas pu localiser ces fichiers (mais j'utilise la version 5.0.4).

@andreasloe mmm, on dirait qu'il a bougé.

/usr/share/grafana/public/build/app.*.js semblait prometteur, mais le changer n'a fait aucune différence pour moi...

@daniellee (ou n'importe quel développeur Grafana) : y a-t-il un moyen pour la communauté d'influencer la priorisation de cette fonctionnalité (format de l'heure de localisation) ? Par exemple, ouvrir une https://www.bountysource.com/ (ou l'équivalent) aiderait-il ? Merci!

@daniellee
Que diriez-vous d'utiliser toLocaleDateString avec navigator.language comme paramètre ?

['en-US','en-IE','en-GB','de-DE','es-ES','nl-NL','pl-PL','ru-RU']
    .forEach(lang => console.log(lang + ': ' + new Date().toLocaleDateString(lang, {day:'numeric', month:'numeric'})))

en-US: 6/4
en-IE: 4/6
en-GB: 04/06
de-DE: 4.6.
es-ES: 4/6
nl-NL: 4-6
pl-PL: 4.06
ru-RU: 04.06

6/4 pour 2018-06-04 est vraiment déroutant.

réf :
https://norbertlindenberg.com/2012/12/ecmascript-internationalization-api/#DateTimeFormat
https://caniuse.com/#feat =internationalisation

+1
La meilleure implémentation serait probablement d'utiliser les unités pertinentes pour la langue (par exemple, en-GB = jj/mm/aa et en-US = mm/jj/aa, etc.), mais en nous donnant une case pour saisir notre propre formatage sur le La page des axes serait la plus flexible et pourrait alors également prendre en charge les options les plus obscures pour des périodes plus longues telles que les mois uniquement, ou à l'autre extrême des minutes uniquement sur les axes.

@hraftery
Malheureusement, pour appliquer les modifications, vous devez recompiler grafana à partir des sources...
Pour modifier localement le format de la date le long de l'axe X :

1. Modifiez le modèle de retour dans la fonction time_format() dans ./public/app/plugins/panel/graph/graph.ts
   if (secPerTick <= 80000) {return '%d.%m.%Y %H:%M';}
2. Si vous souhaitez afficher deux chiffres dans le jour et le mois, ajoutez zéro dans les cas de commutation "d" et "m" dans la fonction formatDate() dans ./public/vendor/flot/jquery.flot.time.js
   case 'd': c = leftPad(d.getDate(), "0"); break;
case 'm': c = leftPad(d.getMonth() + 1, "0"); break;
3. Recompilez Grafana : https://github.com/grafana/grafana/blob/master/README.md

@luxnlex savez -vous comment construire le conteneur docker après la recompilation ? https://github.com/grafana/grafana-docker semble partir de versions de tags que nous n'avons pas à ce stade.

Je serais heureux de fournir et de mettre à jour ce conteneur pendant que l'équipe grafana continue d'insister sur this is quite a small thing et It is only noticeable if you are zoomed out . En regardant le nombre de réponses ici, il semble que ce ne soit pas pour le public ;)

+1
Je vois Grafana comme un logiciel de visualisation de données de séries chronologiques et l'un des meilleurs de sa catégorie, sinon le meilleur.
En tant que tels, les horodatages à l'écran sont essentiels et centraux pour consommer les données visualisées et pour maintenir l'excellente UX.
De nombreuses personnes, entreprises et organisations utilisent Grafana dans le monde entier, en dehors des États-Unis.
Veuillez permettre une configuration facile basée sur l'interface utilisateur, comment les horodatages sont affichés dans différentes cultures. Même un paramètre spécifique à l'instance Grafana serait idéal pour commencer, s'il ne peut pas être spécifique au client du tableau de bord, du graphique ou du navigateur.
Dans mon esprit, ce n'est pas seulement une fonctionnalité manquante normale, mais l'une de ces fonctionnalités de base que les utilisateurs attendent et supposent implicitement d'avoir dans ce type de logiciel super génial (!).

bonjour @torkelo Je ne sais plus à qui demander :-) Serait-il possible pour l'équipe Grafana de nous dire aux heureux utilisateurs non américains un ETA pour cette fonctionnalité ? Merci!

Je peux seulement ajouter - bien que cela ait déjà été dit - qu'il s'agit de la "fonctionnalité" la plus déroutante de Grafana. Chaque fois que je regarde et n'importe quel graphique, je commence à me gratter la tête et j'essaie de comprendre quelle plage de temps je considère vraiment comme totalement inconnue...

Désolé pour le spam mais il fallait le dire. Je pense que cela ne dit pas trop que pour les utilisateurs non américains, ce serait facilement la principale exigence.

Qu'est-ce qui prend si longtemps sur cette question? Je ne peux pas imaginer que ce soit si compliqué...

Je suppose que la communauté devra venir avec un peu de code... ce qui est assez difficile en raison de la nature avec laquelle la date/heure est codée actuellement...

@DerKnerd, il y avait une solution simple (#13429), mais nous ne pensions pas que c'était assez bon. Les problèmes de date deviennent difficiles lorsque vous voulez les résoudre de manière globale.

Ce problème a récemment fait l'objet d'une présentation interne sur le fluage de portée. La voie à suivre est un doc de conception. Si quelqu'un de la communauté souhaite faire du bénévolat, veuillez rejoindre #grafana-dev sur slack.raintank.io et contactez-moi.

@davkal merci d'avoir pointé vers #13429. En fait, pour moi, hors des États-Unis, ce correctif est assez bon et constitue une grande amélioration. Peut-être que ce correctif pourrait être intégré tel quel et le document de conception pourrait être effectué en parallèle ?

@marco-m le point délicat de ce PR est le champ de préférence MonthDate. Nous pourrions éventuellement contourner ce problème si nous modifiions les paramètres de date pour qu'ils soient "par défaut" (c'est-à-dire comment ils sont maintenant, les dates américaines) ou "navigateur" (localisé par les paramètres régionaux du navigateur). La liste déroulante n'aurait que ces deux options. Les navigateurs de vos utilisateurs prennent-ils en charge Date.prototype.toLocaleDateString et auraient-ils les paramètres régionaux que vous souhaitez qu'ils aient ?

@davkal, nous utilisons les dernières versions de Mozilla et Chrome, et nous pouvons mettre à jour n'importe quoi si cela nous permet de contrôler le rendu de la date :-) Et oui, nous pouvons définir sur les navigateurs les paramètres régionaux que nous souhaitons qu'ils aient. Si je comprends bien, je suggérerais de choisir ce qui est « meilleur » du point de vue d'un produit Grafana entre « par défaut » ou « navigateur » ; nous nous ferons un plaisir de nous adapter à votre choix.

@davkal J'ai du mal à voir comment la gestion des dates sans ambiguïté pourrait être considérée comme une dérive de la portée - c'est une source importante de confusion (en particulier pour les utilisateurs non américains, même si je dirais que les dates ambiguës ne devraient jamais être acceptables).

Cela dit, une approche basée sur les paramètres régionaux du navigateur pourrait être une option, bien que cela entraîne-t-il des problèmes pour des choses comme les alertes ? Je soupçonne que cette configuration doit vraiment être conservée et interrogée par utilisateur/par rendu. L'approche strftime / moment.js semble une réponse plus complète, et j'imagine qu'il existe des tables de paramètres régionaux pré-remplies facilement disponibles qui pourraient produire des préréglages pour l'interface utilisateur.

En ce qui concerne les préférences basées sur le navigateur : sachez que les personnes travaillant à l'étranger peuvent choisir d'utiliser un navigateur basé sur l'anglais, d'installer (ou d'être obligées d'installer) celui des États-Unis, puis d'obtenir mm.jj.aaaa.

Pour une solution à court terme, c'est toujours bien, mais le parallèle comme @marco-m devrait être un document complet sur la mise en œuvre d'une véritable localisation avec une préférence de l'utilisateur.

Merci pour tous les commentaires. Personnellement, j'essaierais d'éviter un champ de saisie approprié avec un mappage complet.
Je ne sais pas comment les alertes sont affectées, mais le rendu du serveur nécessiterait que les paramètres régionaux de l'utilisateur soient transmis à un paramètre d'URL (sinon, il utiliserait les paramètres régionaux de phantomjs). Les rendus d'images basés sur Slack devraient également décider d'un paramètre régional à transmettre en tant que paramètre d'URL.

Re mappage complet : doit-il être par serveur grafana, par organisation, par équipe, par utilisateur ?

@davkal a écrit :

J'essaierais d'éviter un champ de saisie approprié avec un mappage complet

Pouvez-vous décrire ce que vous entendez par là ? Je dirai que les utilisateurs ont parfois des préférences particulières en ce qui concerne l'affichage des paramètres régionaux, comme en témoignent les rapports de bogues résultant de la récente implémentation rigide des paramètres régionaux de QT.

Je pense que ce doit être un paramètre par utilisateur, pour prendre en charge les équipes multirégionales, peut-être avec une valeur par défaut à un ou plusieurs des niveaux supérieurs.

Je préférerais vraiment un champ de saisie pour que les gens puissent définir ce qu'ils veulent.
Devoir définir mes paramètres régionaux à un autre endroit pour obtenir le format de date que je veux
se termine toujours par des effets secondaires involontaires et de la frustration.

Avoir un format par défaut à l'échelle du serveur et laisser les utilisateurs outrepasser ce qui rend
le plus sensé pour moi.
De cette façon, le rendu du serveur et les personnes non connectées obtiennent le serveur
par défaut, tandis que les utilisateurs individuels peuvent définir leurs propres formats s'ils en ont besoin.
Je n'utilise pas d'organisations, mais cela pourrait-il avoir du sens de le faire là aussi ?

Le lundi 4 mars 2019 à 09h19, David [email protected] a écrit :

Merci pour tous les commentaires. Personnellement, j'essaierais d'éviter une entrée appropriée
terrain avec une cartographie complète.
Je ne sais pas comment l'alerte est affectée, mais le rendu du serveur aurait besoin du
les paramètres régionaux de l'utilisateur doivent être transmis à un paramètre d'URL (sinon, il utiliserait phantomjs'
lieu). Les rendus d'image basés sur Slack devraient décider d'un paramètre régional à
également passé en tant que paramètre d'URL.

Re mappage complet : doit-il être par serveur grafana, par organisation, par équipe,
par utilisateur ?

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/grafana/grafana/issues/1459#issuecomment-469268689 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABJyGlmAy9ebfDPryZGyVdffLReqBRp8ks5vTSuNgaJpZM4DelGY
.

Exemple pour une cartographie complète : https://github.com/grafana/grafana/pull/13429#issuecomment -430272485

Exemple pour un mapping complet : #13429 (commentaire)

Je soupçonne qu'il peut être inévitable d'avoir une sorte de cartographie comme celle-ci exposée.

À toutes les personnes qui commentent ici et qui en demandent de plus en plus : ce numéro est ouvert depuis février 2015. @davkal a déjà fait un PR qui, bien que pas parfait, est une ÉNORME amélioration par rapport à, eh bien, le rien que nous avons maintenant. Pour moi, il me semble plus productif d'aider ce PR à fusionner, comme point de départ, plutôt que de drainer de @davkal l'énergie qu'il avait pour en faire une réalité. Mes 2 cents.

Si l'on ne se soucie pas d'une interface graphique sophistiquée ou de la prise en charge d'un navigateur/région automagic, est-il possible de patcher la version 6 actuelle à l'exécution ?

@bassebaba oui tu peux. Dans le dossier racine se trouve un public qui contient une construction de répertoire. Il y a un fichier app.<weird stamp>.js , recherchez time_format et vous pouvez remplacer le format.

Connaissez-vous le répertoire si j'exécute grafana sur une framboise (Raspbian GNU/Linux 8, Linux version 4.14.34-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool- ng-1.22.0-88-g8460611)) #1110 SMP lun. 16 avril 15:18:51 BST 2018) ?

Ouais c'est ce chemin : /usr/share/grafana/public/build/app.e16403019d0332233699.js peut-être la partie entre app. et .js est différent.

Merci! BTW, le nom de fichier est app.469095018b321ef1da7c.js

Je dois encore vous déranger. J'ai trouvé la fonction et je l'ai déjà changé en

t.prototype.time_format=function(t,e,n){if(e&&n&&t){var a=ne,r=a/t/1e3;return r<=45?"%H:%M:%S": r<=7200||a<=86400010?"%H:%M":r<=8e4?"%d.%m %H:%M":r<=2419200||a<=31536e6?"% d.%m":"%m.%Y"}return"%H:%M"},t}();

mais en vain. J'ai également redémarré le serveur et il est dit

`● grafana-server.service - Instance Grafana
Chargé : chargé (/usr/lib/systemd/system/grafana-server.service ; activé)
Actif : actif (en cours d'exécution) depuis Di 2019-03-05 19:52:28 CET ; il y a 3min 39s
Documents : http://docs.grafana.org
PID principal : 1795 (serveur grafana)
Groupe C : /system.slice/grafana-server.service
└─1795 /usr/sbin/grafana-server --config=/etc/grafana/grafana.ini --pidfile=/var/run/grafana/grafana-server.pid --packaging=...

Mars 05 19:52:28 FHEM grafana-server[1795]: t=2019-03-05T19:52:28+0100 lvl=info msg="Initializing HooksService" logger=server
Mars 05 19:52:28 FHEM grafana-server[1795]: t=2019-03-05T19:52:28+0100 lvl=info msg="Initializing InternalMetricsService" logger=server
Mars 05 19:52:28 FHEM grafana-server[1795]: t=2019-03-05T19:52:28+0100 lvl=info msg="Initializing CleanUpService" logger=server
Mars 05 19:52:28 FHEM grafana-server[1795]: t=2019-03-05T19:52:28+0100 lvl=info msg="Initializing NotificationService" logger=server
Mars 05 19:52:28 FHEM grafana-server[1795]: t=2019-03-05T19:52:28+0100 lvl=info msg="Initializing ProvisioningService" logger=server
Mars 05 19:52:28 FHEM grafana-server[1795]: t=2019-03-05T19:52:28+0100 lvl=info msg="Initializing PluginManager" logger=server
Mars 05 19:52:28 FHEM grafana-server[1795]: t=2019-03-05T19:52:28+0100 lvl=info msg="Démarrer la recherche de plugins" logger=plugins
Mars 05 19:52:29 FHEM grafana-server[1795]: t=2019-03-05T19:52:29+0100 lvl=info msg="Initializing TracingService" logger=server
Mars 05 19:52:29 FHEM grafana-server[1795]: t=2019-03-05T19:52:29+0100 lvl=info msg="Initializing Stream Manager"
Mars 05 19:52:29 FHEM grafana-server[1795]: t=2019-03-05T19:52:29+0100 lvl=info msg="HTTP Server Listen" logger=http.server addr...socket=
Astuce : Certaines lignes étaient elliptiques, utilisez -l pour les afficher en entier.
`

Voici une capture d'écran

@andreasloe serait-il possible pour vous de trouver un autre endroit pour demander votre aide spécifique ? J'ai encore l'espoir que ce ticket soit fermé comme fixé dans Grafana. Merci :-)

@andreasloe pas sûr. Peut-être que vous utilisez une version plus ancienne que moi. Mais comme l'a dit @marco-m, posez peut-être une question sur Stackoverflow ou reddit. Quelqu'un peut sûrement vous aider :slightly_smiliing_face:

Ping @torkelo @daniellee Je me rends compte que j'ai en quelque sorte levé le drapeau sur la négligence de la communauté auparavant (https://github.com/grafana/grafana-plugin-repository/issues/332), mais c'est toujours à mon humble avis le pire fonctionnalité manquante dans Grafana, maintenant en v6.3 ! Il a 4 ans. En dehors des États-Unis, nous ne cherchons pas une solution globale. Pour le moment, nous serions probablement totalement satisfaits de toute amélioration au cours du néant de 4 ans.

S'il vous plaît, regardez à nouveau le PR existant ou une meilleure solution, et aidez-nous. Je ne suis pas un gars de frontend, mais tout ce que je pourrais contribuer s'il vous plaît faites le moi savoir.

Pour être un peu plus précis, à quel point cette demande est importante. J'ai effectué une vérification rapide des statistiques à l'aide de l'API GH pour ce référentiel :

2010 open issues, thereof
1163 feature requests
4938 comments on feature requests
126 comments on most commented feature requests

Principales demandes :

• #6557 (126 commentaires)
• #1959 (108 commentaires)
• #6983 (104 commentaires)
• #3752 (84 commentaires)

Cette demande ici a 97 (!) commentaires et se classe donc au n°4. Il n'est pas visible dans cette liste car il n'est pas étiqueté comme type/feature-request .

Si je relance l'analyse sans filtrer par balise, elle apparaît directement dans le top 4 :

• #6557 (126 commentaires)
• #1959 (108 commentaires)
• #6983 (104 commentaires)
• #1459 (97 commentaires)

Est-ce une preuve suffisante que ce problème n'est pas « une petite chose » ?

Ayant travaillé avec flot auparavant, je serais heureux de faire une proposition à quoi cela pourrait ressembler dans une version de base, étant donné que nous pouvons obtenir de l'aide pour l'équipe de base pour l'implémenter réellement. Mise à jour : pas nécessaire car le PR ouvert en a déjà une bonne partie.

Ouais c'est dingue. Je ne mets même pas régulièrement à jour grafana car je dois alors trouver comment "pirater" à nouveau l'affichage de l'heure.
(Je suis toujours en v6 :P)

J'ai quelques plans pour l'automatiser avec des scripts bash dans une image Docker que je peux ensuite simplement reconstruire chaque mise à jour, mais c'est juste une façon folle de corriger cette fonctionnalité manquante.

Je regarde maintenant https://github.com/grafana/grafana/pull/13429 . Je vais essayer de réappliquer au maître actuel. C'est au-delà de ma zone de confort mais ça a l'air bien fini.

Rien de tout cela n'aidera à moins que l'équipe principale n'accède à sa demande de fonctionnalité de 4e rang le plus élevé ...

Wow! C'est insensé!

Je viens de passer un moment important à chercher un moyen de modifier le format de date de l'axe des x dans les paramètres de grafana. C'est une fonctionnalité tellement basique et nécessaire qu'elle ne m'est pas venue à l'esprit qu'elle pourrait être encore à implémenter.

Je serais vraiment heureux si vous pouviez en parler sous peu :)

Copié à partir de #18659 :

Rappel rapide que #13429 n'a pas réussi car seul le format du mois a été pris en compte. ...
La première étape devrait être d'ajouter un commentaire sur #1459 à propos de vos intentions, puis de rejoindre le public slack sur slack.grafana.com.

@davcal, il n'était pas

Du point de vue de l'utilisateur en difficulté, je m'en ficherais vraiment. Un formulaire simple pourrait simplement combiner tous les paramètres, comme @torkelo l'a suggéré, dans une liste déroulante avec des valeurs par défaut raisonnables pour les États-Unis et certains pays. US pourrait ressembler à une version concaténée de :
...
Cela pourrait se terminer dans la configuration json comme suggéré par @torkelo. Tout ce qui ne commence pas par un P serait le format par défaut. Une entrée "personnalisée" dans la liste déroulante permettrait de spécifier ma propre chaîne de format, peu importe si j'ai besoin de construire cette interface utilisateur grafana en dehors car c'est vraiment une tâche unique et les PR pour des valeurs par défaut supplémentaires seraient facilement effectuées à partir de là.

Alors qu'une version polie serait géniale, après plus de 4 ans d'attente, moi (et probablement la plupart des utilisateurs) serions heureux d'avoir n'importe quoi.

Donc, avant de faire quoi que ce soit d'autre (comme écrire un document de conception), j'aurais besoin d'être convaincu que Grafana est, même de loin, intéressé, s'engage dans la discussion et avance avec l'une des demandes de fonctionnalités les mieux classées :(

Je suis aussi frustré. Pour être clair, lors de la démonstration de nos piles de services à l'aide de Grafana pour la visualisation, je dois toujours excuser nos clients, qui posent des questions sur le format de la date, que Grafana (autrement génial) ne sait pas et ne peut pas être configuré pour afficher les horodatages comme les clients veulent. Cela ruine toutes les premières démonstrations car vous devez toujours expliquer pourquoi une telle fonctionnalité frontale et très visible ne fonctionne pas. C'est une fonctionnalité de base et elle ne fonctionne pas, car elle ne donne pas ce que les clients veulent. Veuillez commencer à vous occuper de ce problème, s'il vous plaît.

+1, vraiment frustrant, je ne peux pas obtenir de formats de date internationaux sur la série X.

Je serais heureux et favorable à une approche autour d'un mappage de format, avec des valeurs par défaut pour les paramètres régionaux populaires. Nous recherchons cependant quelqu'un dans la communauté pour prendre en charge cet effort. Je suis disponible pour tout conseil.

Voici un aperçu des travaux nécessaires :

• vous pouvez utiliser #18659 comme point de départ, merci @andig
• spécifier un mappage de date qui a des formats pour différentes résolutions temporelles
• réécrire potentiellement le monthDayFormat pour stocker le mappage sélectionné
• ajouter une logique pour utiliser le mappage dans le formateur de date graphique
• ajouter des mappages pour les paramètres régionaux populaires dans une liste déroulante
• fournir une option personnalisée dans la liste déroulante pour fournir son propre mappage
• ajouter la gestion des erreurs autour du mappage personnalisé
• écrire des tests pour la validation de mappage
• mettre à jour la documentation

S'il vous plaît contactez-moi ou @torkelo sur notre mou public si vous voulez prendre cela. Avant de commencer tout travail, assurez-vous de poster ici également. Voir aussi nos lignes directrices pour les contributions .

C'est super de voir ça bouger !

spécifier un mappage de date qui a des formats pour différentes résolutions temporelles

Je pense que ce que nous pouvons faire ici est de proposer une liste complète de formats de date. Cependant, nous devons d'abord clarifier les paramètres.
Le code actuel repose à la fois sur la longueur des graduations et la plage du graphique pour choisir le formatage. Le flottant d'origine n'utilise que la longueur des ticks et vérifie si la longueur est inférieure à des intervalles fixes (minute, jour, mois, année). Si nous voulons que cela reste flexible, je proposerais :

• rendre les intervalles configurables
• utiliser la notation ISO (prise en charge par Go et momentjs)
• vérifiez la longueur des coches par rapport aux intervalles, si en dessous de l'intervalle vous avez votre format
• il devrait y avoir des paramètres régionaux préconfigurés et la possibilité d'utiliser votre propre format

Cela nécessiterait quelque chose comme une table de mappage comme suggéré dans https://github.com/grafana/grafana/pull/13429. Les États-Unis pourraient ressembler à ceci (besoin de vérifier les chaînes de format de moment). N'oubliez pas que les durées seraient la limite supérieure de la taille des ticks :

[
    ["PT1S", "HH:mm:ss.SSS"],
    ["PT1M", "HH:mm:ss"],
    ["P1DT", "MM/DD HH:mm"],
    ["P1MT", "MM/DD"]
    ["P1YT", "YY-MM"]
    ["", "YYYY"]
]

L'Allemagne ressemblerait à ceci :

[
    ["PT1S", "HH:mm:ss.SSS"],
    ["PT1M", "HH:mm:ss"],
    ["P1DT", "DD.MM HH:mm"],
    ["P1MT", "DD.MM"]
    ["P1YT", "MM/YY"]
    ["", "YYYY"]
]

UK (hypothèse) ressemblerait à ceci (format 12 heures) :

[
    ["PT1S", "hh:mm:ss.SSS"],
    ["PT1M", "hh:mm:ss"],
    ["P1DT", "DD/MM hh:mm"],
    ["P1MT", "DD/MM"]
    ["P1YT", "MM/YY"]
    ["", "YYYY"]
]

Le formatage peut venir dans un fichier de configuration ou basé sur l'interface utilisateur. Pour l'interface utilisateur, il peut être judicieux d'avoir des paramètres par défaut pour les paramètres régionaux populaires (au moins aux États-Unis) et d'autoriser une configuration basée sur l'utilisateur en texte libre. Ce dernier pourrait simplement être :

<duration literal> <momentjs format string>, repeat as needed

Cette discussion est un peu folle. Il montre, en public, une déconnexion entre certains des principaux développeurs de grafana et certains de ses utilisateurs.

En tant qu'utilisateur européen (et développeur mais pas de grafana dev), j'aimerais certainement cette fonctionnalité. Je suis également conscient que grafana est (à ma connaissance) développé principalement par des personnes bénévoles pendant leur temps libre, et en tout cas, tous les projets de développement doivent être prioritaires.

Peut-être que les personnes qui voudraient contribuer à la réalisation de cette fonctionnalité pourraient s'identifier. Il a été souligné que les développeurs de grafana communiquent sur Slack, ce qui pourrait être le bon endroit pour le faire. Et ensuite, que ces personnes restent conscientes que tous les projets ont des procédures et qu'elles devront se conformer à tout ce que cela signifie ici.

Et peut-être qu'un développeur de grafana pourrait s'identifier comme un mentor patient pour aider ces personnes à accomplir la tâche d'intégrer cette fonctionnalité dans la branche principale. Je pense que cela vient de se produire avec @davkal . (Gloire.)

@JeffAbrahamson

En tant qu'utilisateur européen (et développeur mais pas de grafana dev), j'aimerais certainement cette fonctionnalité. Je suis également conscient que grafana est (à ma connaissance) développé principalement par des personnes bénévoles pendant leur temps libre, et en tout cas, tous les projets de développement doivent être prioritaires.

Exactement. Je suis mal à l'aise avec l'hypothèse du droit dans _certains_ des commentaires, oubliant que Grafana est _gratuit_ et _open source_, comme je l'ai mentionné un peu plus haut à https://github.com/grafana/grafana/issues/1459#issuecomment -469317707.

Je veux juste remercier encore une fois @davkal pour ses tentatives et pour sa générosité.

Si mon commentaire a offensé, je m'en excuse sincèrement. Je suis très reconnaissant pour le travail fourni par tous pour ce projet.

@andig - Votre hypothèse sur le format de date britannique semble solide, si c'est une bonne solution.

Une alternative, si je peux être aussi audacieux - et ne connaissant aucun des éléments internes, je ne sais pas si c'est une suggestion valide, alors s'il vous plaît jeter sinon : Une simple boîte sur la page Style d'un graphique qui permet à l'utilisateur de coller dans un format de date prioritaire pour l'échelle X. Peut-être en utilisant le format d'extension de chaîne commun utilisé ailleurs, comme en php ; https://www.php.net/manual/en/function.date.php pourrait donner une interprétation complète et libre et s'adapter à tous les cas d'utilisation sur une base graphique, plutôt que d'appliquer un format pour tous. (A l'usage, j'ai parfois envie d'afficher le jour de la semaine plutôt qu'une date par exemple)

Quelque chose peut-être :

Remplacer le format de date X [ ]

Qui, s'il est défini, étendrait les jetons comme
%D %d, %M au lun 12, sept.

%D %G:%H au Lun 13:45

Meta : juste pour clarifier le développement de Grafana est dirigé par le personnel de Grafana Labs d'environ 25 développeurs (moi y compris). Mais si vous considérez la taille du logiciel, la taille du personnel est assez faible, et le logiciel ne serait pas si utile sans toutes les contributions de la communauté. Notre défi pour des fonctionnalités comme celle-ci ici, qui ne sont pas urgentes mais importantes, nous aimerions trouver un moyen de permettre à la communauté de développer la fonctionnalité. Nous avons de nombreuses histoires à succès de contributions individuelles importantes, et je serais plus qu'heureux de vous guider tout au long de ce processus ([email protected]).

Une case simple sur la page Style d'un graphique qui permet à l'utilisateur de coller dans un format de date prioritaire pour l'échelle X.

Je suis moins fan car changer cela dans tout le système sera un fardeau permanent lorsque de nouveaux tableaux de bord seront ajoutés dans l'organisation de l'utilisateur. Jusqu'à présent, je préconise toujours l'approche décrite ci-dessus.

Par souci de transparence : j'ai poussé le rebase aussi loin que possible sans a) la capacité de tester (voir pr pour les problèmes rencontrés) et b) des connaissances approfondies en développement frontend. Désolé de dire que vous devrez me compter.

+1, nous préférerions de loin autre chose que le format MMDD :)

Comment personnaliser le format datetime d'une série dans un tracé ? Dites supprimer l'heure, modifier le format de la date ou ajouter des secondes ?

+1

Le correctif ci-dessus ne fonctionne pas pour moi avec Grafana 6.7.1 Mais :

bash -c "trouver /usr/share/grafana/public -type f -exec sed -i 's@%m/%d@%d/% m@g ' {} +"

NB Je l'exécute dans un conteneur Docker, mais sinon, je ne suggère pas de l'exécuter sans d'abord sauvegarder les fichiers dans /usr/share/grafana/public.

Mais cela fonctionne pour moi.

Pour écraser le point d'entrée par défaut dans docker-compose :
point d'entrée : bash -c "find /usr/share/grafana/public -type f -exec sed -i 's@%m/%d@%d/% m@g ' {} + && /run.sh "

Merci, pour ceux qui veulent la version allemande (1.4 au lieu de 1/4) puis la suivante ?
bash -c "trouver /usr/share/grafana/public -type f -exec sed -i 's@%m/%d@%d.% m@g ' {} +"
Ou ai-je besoin d'un caractère spécial devant le point ?

excuses, je ne fonctionne pas, je reviendrai si je trouve une solution,

Le correctif ci-dessus ne fonctionne pas pour moi avec Grafana 6.7.1 Mais :

bash -c "trouver /usr/share/grafana/public -type f -exec sed -i 's@%m/%d@%d/% m@g ' {} +"

NB Je l'exécute dans un conteneur Docker, mais sinon, je ne suggère pas de l'exécuter sans d'abord sauvegarder les fichiers dans /usr/share/grafana/public.

Mais cela fonctionne pour moi.

Pour écraser le point d'entrée par défaut dans docker-compose :
point d'entrée : bash -c "find /usr/share/grafana/public -type f -exec sed -i 's@%m/%d@%d/% m@g ' {} + && /run.sh "

N'est-ce pas gentil. Une autre année s'est écoulée, Grafana approche de la version 7, la localisation est considérée comme "une petite chose" bien qu'elle soit la 4ème demande de fonctionnalité la mieux classée et nous piratons ici les binaires...

Oui, je serais intéressé d'avoir un mot avec le propriétaire du produit. Pourquoi cette demande de fonctionnalité n'est-elle pas plus élevée sur la liste ? Forte demande, possible, longue histoire, augmentation des ventes/de la convivialité... de quoi d'autre un bon de commande aurait-il besoin ?

@davkal pourriez-vous gentiment marquer cela comme type/feature-request selon https://github.com/grafana/grafana/issues/1459#issuecomment -523313533 afin qu'il apparaisse au moins dans vos priorités ?

Je suis l'un des propriétaires de produits et j'ai répertorié mon e-mail et le public slack comme moyens d'entrer en contact. Personne ne m'a contacté.

Notre invitation à contribuer est toujours ouverte. Les étapes sont décrites ci-dessus. Nous sommes en train de mûrir en tant qu'organisation d'ingénierie, donc pour cette entreprise, la partie qui aimerait travailler là-dessus devrait commencer un document de conception. Voir celui-ci pour un exemple .

Je suis l'un des propriétaires de produits et j'ai répertorié mon e-mail et le public slack comme moyens d'entrer en contact. Personne ne m'a contacté.

@davkal je ne sais pas comment réagir mais ce que tu écris me rend triste :

• J'ai personnellement essayé de souligner l'importance de cette demande https://github.com/grafana/grafana/issues/1459#issuecomment -523313533
• essayé de transmettre la spécification https://github.com/grafana/grafana/issues/1459#issuecomment -528817275
• J'ai essayé, bien qu'avec des compétences limitées, de pousser plus loin un PR abandonné (https://github.com/grafana/grafana/pull/18659) et j'ai demandé de l'aide https://github.com/grafana/grafana /pull/18659#issuecomment -523422092
• on a dit qu'il fallait abandonner :

Ne pas aller de l'avant avec cela, voir aussi #13429

• été dit dans https://github.com/grafana/grafana/pull/13429 que :
  Ne pas aller de l'avant avec cela, réessayera avec une approche plus globale.

Et comment tu dis :

Personne ne m'a contacté.

Je n'en dirai pas plus mais je ne me sens pas apprécié pour le moment.

Vos efforts ont certainement été appréciés @andig et vous avez essayé de faire avancer le problème. Ce que je veux dire, c'est qu'il n'y a pas eu d'autre discussion que la nôtre (celle ci-dessus en septembre 2019).

Pour clarifier encore une fois : la localisation des formats de graphiques a beaucoup de sens, et c'est sur la feuille de route. On pourra peut-être même y arriver cet été, mais ne comptez pas sur nous pour ça, les feuilles de route peuvent changer. Si cette fonctionnalité vous apportera de la valeur, n'hésitez pas à contribuer et à y arriver plus tôt.

J'espère qu'il sera bientôt là, grafana manque de certaines fonctionnalités de base comme celle-ci (format date avec paramètres utilisateur...)

Il semble que les paramètres de requête d'url de stackdriver timeRange attendent des heures au format ISO 8601 et non des horodatages unix. Avoir l'heure au format ISO pour cela déverrouillerait la liaison au stackdriver à partir des panneaux (avec l'heure actuelle). Merci pour tout ce dur travail!

Quelqu'un peut-il fournir une solution SED/patch pour Grafana 7 ? (m/j) -> (j/m)

Petite RP pour améliorer les choses. https://github.com/grafana/grafana/pull/25602.
Suggère d'utiliser le format de navigateur local pour le panneau graphique.

Il semble qu'une option arrive bientôt, mais pour ceux qui recherchent une solution rapide :

for i in /usr/share/grafana/public/build/*.js; do sudo sed -i 's@MM/DD@DD/MM<strong i="6">@g</strong>' "$i"; done

Fonctionne sur Grafana v7

+1, je ne peux pas croire qu'une chose aussi insignifiante soit en discussion depuis plus de 5 ans
les utilisateurs professionnels de Grafana souffrent-ils également du même problème ?

Ha ha. 5 ans ont passé. C'est une honte.

Veuillez donner la priorité à ce problème. Les graphiques avec le formatage mm/dd sont donc inutiles.

Je ne me soucie pas de la solution parfaite consistant à permettre à chaque utilisateur de choisir un formatage individuel, un seul paramètre système pour le formatage de la date est ok tant que je suis en mesure d'éviter l'exposition à cette horrible anomalie de formatage de date.

Les options de formatage de la date du système viennent d'être fusionnées https://github.com/grafana/grafana/pull/27216

Ajoute ces paramètres ini

[date_formats]
# For information on what formatting patterns that are supported https://momentjs.com/docs/#/displaying/

# Default system date format used in time range picker and other places where full time is displayed
full_date = YYYY-MM-DD HH:mm:ss

# Used by graph and other places where we only show small intervals
interval_second = HH:mm:ss
interval_minute = HH:mm
interval_hour = MM/DD HH:mm
interval_day = MM/DD
interval_month = YYYY-MM
interval_year = YYYY

# Experimental feature
use_browser_locale = false

S'il vous plaît tester et donner votre avis. Prévoyez d'ajouter des paramètres au niveau de l'organisation pour cela également dans une future version. Le use_browser_locale a encore quelques problèmes à corriger (détecter 12 vs 24 heures). Une option first_day_of_week pourrait également être un bon ajout à cela.

Merci @torkelo très apprécié !

Voici un exemple

Configuration :

[date_formats]
# Default date format
full_date = MMM Do, YYYY @ hh:mm:ss a
# Used by graph and other places where we only show small intervals
interval_second = hh:mm:ss a
interval_minute = hh:mm a
interval_hour = MMM DD hh:mm a
interval_day = MMM DD
interval_month = YYYY-MM
interval_year = YYYY

C'est une excellente nouvelle, merci beaucoup ! J'ai redémarré grafana mais le nouveau format ne s'est pas affiché. Quelle version dois-je installer - pouvez-vous m'indiquer un site expliquant cela ?

Compilez ou attendez la version bêta de la version 7.2 (très bientôt)

Compilez ou attendez la version bêta de la version 7.2 (très bientôt)

Comment est souvent la balise maître à dockerhub mis à jour? Il a deux jours, serait-il possible de le déclencher plus souvent ?

Nice one @torkelo - ce qui suit fonctionne bien sur l'image docker grafana:7.3.5 (extrait docker-compose.yml):

version: '2.0'
services:
  grafana:
    image: grafana/grafana:7.3.5
    environment:
      - GF_DATE_FORMATS_INTERVAL_HOUR=DD/MM HH:mm
      - GF_DATE_FORMATS_INTERVAL_DAY=DD/MM

Cependant, le réglage de GF_DATE_FORMATS_USE_BROWSER_LOCALE=true n'a pas fonctionné pour moi ici en Australie, en utilisant Firefox sur un mac - les formats de date courts sont restés au format MM/DD spécifique aux États-Unis.