sim, melhores opções para isso devem ser adicionadas. Não tenho certeza de qual é a melhor maneira, acho que pode haver um PR para isso que foi enviado há muito tempo e que ainda não tive tempo de revisar.

Legal, obrigado!
Agora, reconstruí a grafana com formato europeu codificado no meu projeto =)

Isso seria útil, pois o formato de data europeu não está na mesma ordem (dia / mês / ano), as datas são realmente confusas

+1

+1

+1

Para qualquer outra pessoa que queira consertar isso;
Eu uso isso para minha construção solaris.

Tenta public_gen incase grunt já foi executado.

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

! / bin / bash

set -e

correção(){
echo -e "Tentando fazer o patch em; n $ GRAPHJSFOLDER"
ORIG = $ GRAPHJSFOLDER / 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
correção
GRAPHJSFOLDER = $ GRAFANAROOT / public_gen / app / panels / graph
correção
`` `

+1

+1

+1 sobre isso, forçar a localidade dos EUA MM / dd em gráficos não é o ideal. Possivelmente ajudado pelos locais introduzidos com # 5517?

+1

+1, isso está bloqueando a adaptação em nossa empresa

@tokudan Ei, isso é o que fizemos em nossa solução; https://github.com/grafana/grafana/issues/1459#issuecomment -162446127

Seria maravilhoso se isso levasse a localização real do navegador em consideração ou se os usuários pudessem pelo menos configurá-lo manualmente. Forçar todos a usar datas no estilo americano é realmente muito abaixo do ideal.

+1

+1

Seria ótimo quando a data pudesse ser geralmente personalizada. Exemplo:
Em vez de ter
21-11-2016 21:19:00
Eu gostaria de ver o dia da semana, bem como uma data abreviada (formato alemão aqui):
Mo, 21,11., 21:19

@RyanCarrier tem alguma ideia de como fazer essa modificação sem construir a partir do código-fonte? Encontrei o arquivo equivalente na minha instalação do Ubuntu (do pacote deb) aqui:

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

Infelizmente, modificar esse arquivo, reiniciar grafana-server e atualizar o navegador não pega a mudança. Eu localizei esta versão reduzida:

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

e pensei que era um vencedor, mas, infelizmente, mesmo resultado. Você sabe se há outra saída de compilação que a grafana usa que explicaria por que modificar esses arquivos não faz diferença?

Ei cara, se o script que escrevi anteriormente não funcionar e você ainda estiver tendo problemas, responda e eu darei uma olhada quando tiver algum tempo de volta para casa (Provavelmente no 2 ou 3).

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

Oh, desculpe, eu não percebi do pacote deb. Vou ter que dar uma olhada em casa e dar uma olhada no meu servidor. Bata em mim se eu não responder até o dia 3. :)

Esbarrando em @RyanCarrier - não fui descobrir isso. Suspeito que seja algo simples, mas não consigo fazer o Grafana pegar nenhuma mudança que eu fiz em graph.ts (sem compilar a partir do código-fonte, o que eu prefiro evitar se possível).

eles mudaram as coisas desde a última vez que joguei, e eu não tenho um ambiente como naquela época. Mas encontrei% m /% d em alguns arquivos; para mantê-lo atualizado.

public / app / app_bundle.js: 13
public / app / boot.js: 18
public / app / boot.fnsdmjkfnasjk.js
o resto está em
public / app / plugins / panel / graph

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

Ei então é o estranho boot.123456.js em / usr / share / grafana / public / app.

Só para garantir, eu mudaria no boot.js também, presumo que seja compilado quando você o instala.

apenas execute aquele comando sed que fiz, apenas lembre-se de que seus números serão diferentes, mas;

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

em seguida, basta atualizar a página (ctrl shift r). Probs funciona com atualização regular. Mas de qualquer forma.

Sorrry, demorei tanto que esqueci completamente.

o comando apenas substitui todos os% m /% d por% d /% m

Eu também iria executá-lo nos outros arquivos, para o caso de eles serem unidos durante a recompilação ou atualização ou algo assim.

Isso foi o suficiente! A atualização regular foi o suficiente. Os outros arquivos que você mencionou também estão presentes e contêm a string.

Um pouco misterioso. Suspeito que será um conhecimento útil para outras questões que surgirem. Muito obrigado!

Existe uma maneira de alterar o formato de data por meio da GUI ou configurações do Grafana? Posso ver algumas conversas sobre como fazer alterações nos arquivos de origem, o que prefiro não fazer :)

@ leinad13 No momento, não, por isso o recurso aos arquivos de origem. Não é o ideal, mas realmente muito fácil.

Isso deve funcionar, executado a partir da linha de comando em seu servidor:

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}

Em seguida, basta atualizar a página Grafana do seu navegador.

+1 também para mim

Ok, tropecei nisso ao comparar Grafana a Kibana. Infelizmente, não oferecer suporte a configurações de local (formatos de data / hora / número etc.) é um obstáculo para o Grafana em ambientes profissionais (simplesmente não é possível entregar um projeto com um local errado). Seria muito bom se isso fosse corrigido com prio (e sem patches desagradáveis ​​de origem). @torkelo

+1

+1

+1

No meu caso, estou tendo problemas com datas no eixo X, às vezes mostrando apenas a parte do tempo, às vezes com a data (formato dos EUA, EU aqui) e não consigo controlar de forma previsível. De alguma forma relacionado a # 3591

+1

+1

+1

À primeira vista, o código flot (jquery) é usado. Lá, você tem opções de formatação, se forem passadas. Veja jquery.flot.time.js
Para uso global, uma boa localização é crucial. E, por favor, não se limite às opções tiradas automaticamente das configurações do navegador. Usar um idioma com base nos EUA não significa que eu quero ter a localização dos EUA não conforme ...

+1

+1, como uma solução alternativa, eu uso agora as visualizações de 23h para desabilitar a exibição de datas estranhas nos principais casos de uso.

+1

+1

Ficaríamos muito gratos se você priorizasse esse problema. É realmente confuso para os usuários europeus. Muito obrigado!

+1

+1

+1

+1

Não posso implementar isso no Reino Unido com formatos de data dos EUA, porque as pessoas certamente lerão a data incorretamente.

Só para ficar claro sobre isso - os EUA são basicamente o único país do planeta que usa o formato de data M / D / Y. O resto do mundo acha esse formato muito confuso. Veja https://en.wikipedia.org/wiki/Date_format_by_country

Por não suportar formatos de data locais, você está efetivamente dizendo a qualquer pessoa fora dos EUA que ela não deve usar o Grafana.

Use pelo menos, digamos, ISO 8601 como padrão se não puder ser configurado. Essa deve ser uma correção simples que pode ser implementada imediatamente.

Não posso acreditar que esse bug foi registrado há três anos.

Sim, ISO 8601 é uma boa solução de curto prazo.

Não parece que o Grafana tenha vontade ou apetite para fazer isto, originalmente não tinha reparado que este ticket foi criado há 3 anos!

não é como se não quiséssemos, mas a menos que você não tenha notado, existem cerca de 1000 solicitações de recursos abertos :)

Espero que você perceba que isso é mais do que um FR. Este é um bloqueador para adoção fora dos EUA. Parece uma decisão na codificação há muito tempo que está tendo efeitos colaterais desagradáveis ​​agora.

Eu dei a vocês soluções duas vezes no início deste tópico. Se você é realmente um problema para você e você não pode fazer as soluções alternativas por algum motivo. Faça você mesmo a mudança. O objetivo do código aberto é poder contribuir e trabalhar juntos, não chorar que esses voluntários não estejam fazendo exatamente o que você deseja.

@RyanCarrier Sentimos muito por mantê-lo afastado de suas tarefas tão importantes. Também lamentamos por empurrar nosso recurso favorito para os 1000 de outros FRs.
Provavelmente começaremos a chorar às portas da empresa por trás da Grafana a partir de agora: https://grafana.com/services/support

Em primeiro lugar, isso é uma coisa pequena. Só é perceptível se você diminuir o zoom e passar o mouse sobre um ponto, poderá ver a data inteira. Não entendo o argumento de que este é um bloqueador para adoção fora dos EUA. (Eu uso Grafana desde o primeiro dia e moro na Suécia e nunca percebi esse problema).

Na verdade, dei uma olhada nisso na semana passada, mas era mais complicado do que eu pensava. Fiz um aumento rápido para tentar descobrir automaticamente o formato do dia do mês por localidade - tanto com MomentJS quanto com Date.prototype.toLocaleDateString () .

MomentJS não tem suporte para o formato mês / dia por local, mas toLocaleDateString pode funcionar. O problema é que depende das configurações do seu navegador (configurações de idioma no Chrome) para que a maioria das pessoas obtenha o formato americano de qualquer maneira, mesmo que estejam localizadas na Europa.

Chegamos à conclusão de que a única maneira de fazer isso seria adicioná-lo como uma definição de configuração (com opções: usar o local do navegador ou definir explicitamente).

PS @mvhconsult Grafana é um projeto de código aberto e a maioria dos lançamentos consiste principalmente de recursos e correções de bugs contribuídos pela comunidade Grafana. Você não está pagando nada pelo Grafana e nunca contribuiu com nenhuma correção ou recurso, então tente manter o tom civilizado.

@daniellee Com o risco de começar uma discussão real fora do tópico aqui, então essa é a última de mim. Estou envolvido com código aberto nos últimos 15 anos, então sei como é receber todos aqueles pedidos que parecem sem importância para você. Com certeza a maioria não está visível aqui.
Uma maneira de envolver as pessoas e gastar seu precioso tempo olhando para outro projeto (há vida fora de Grafana) é dar-lhes dicas de como trabalhar e razões pelas quais as coisas não são captadas pela equipe principal, junto com o bem código documentado. A maneira de assustar as pessoas (ou mesmo de fazer com que "por que eu me importaria novamente com este produto ou equipe") é dizer a eles que é um absurdo, que eles deveriam apenas cavar no código-fonte e implementar alguns patches intermediários por si próprios, e menosprezá-los, dizendo-lhes que eles gemem / choram. Se a política aqui é que apenas contribuidores de código podem fazer solicitações: por mim tudo bem, estou de volta à vida real.

@mvhconsultar ninguém da equipe principal disse que essa solicitação de recurso é um absurdo. Estou na equipe principal e passei um tempo procurando uma solução. Talvez você não tenha percebido que recentemente atribuí esse problema a mim mesmo. Eu também queria apenas salientar que este é um pequeno problema e não algo que marcaríamos como prioridade 1 (é um problema absolutamente válido, mas não afeta a maioria das pessoas e mesmo as pessoas que percebem podem facilmente contorná-lo).

Discussões sobre solicitações de recursos são boas (e encorajadas), mas achei que isso era desnecessário:

Provavelmente começaremos a chorar às portas da empresa atrás da Grafana a partir de agora:

É por isso que perguntei se você pode diminuir um pouco o tom. Obrigado.

Se você quiser fazer isso, será um prazer ajudá-lo a começar. Você pode começar configurando o Grafana para desenvolvimento: http://docs.grafana.org/project/building_from_source/

@daniellee isso definitivamente NÃO é uma coisa pequena e não há uma "solução alternativa fácil" até onde eu sei.

É extremamente comum ter gráficos que mostram mais de um único dia de dados, por exemplo, semana, mês ou ano anterior, e todos esses gráficos mostram datas no formato MM / DD no eixo. Você não precisa passar o mouse sobre nada para ver essas datas formatadas incorretamente.

Parece que você não está enfrentando o problema, mas certamente o número de "+1" neste tópico deixa claro que muitas pessoas têm problemas com ele.

Acho que a maioria das pessoas também aprecia as dificuldades de executar um projeto popular de código aberto, especialmente quando há muitas solicitações de recursos e recursos mínimos. Este é exatamente o motivo pelo qual alguns de nós defendemos esse problema - estamos tentando argumentar que esse é um grande problema para MUITAS pessoas e seria ótimo se pudesse ser resolvido.

@andymadge legal, posso entender que outras pessoas possam ter uma visão totalmente diferente da minha e, como você disse, muitas pessoas votaram a favor. Este recurso será implementado em breve, pois a formatação do tique está errada para a maior parte do mundo e deve ser corrigida.

Só estou tentando descobrir a maneira mais amigável de apresentar essa opção. Acho que vou mudar o formato de escala para o padrão toLocaleDateString () com o primeiro idioma em navigator.languages mas tenho uma opção de configuração para definir o formato de mês / dia (ou dia / mês) nas preferências do usuário.

Tenho uma pergunta que talvez alguém de um país com um formato de data que inclui pontos ou algo semelhante (Finlândia, Alemanha ou Coreia do Sul, por exemplo) possa responder.

É normal ter apenas duas opções explícitas: mm/dd ou dd/mm . 20 de outubro seria 10/20 ou 20/10 .

@daniellee soa bem para mim.

Estou certo em dizer que os carrapatos mostram apenas mês e dia, ou ano e mês, nunca todos os 3 juntos?

@andymadge sim, você está certo. Existem diferentes formatos para os diferentes níveis de zoom. Começando no máximo com menos zoom:

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

Os que vou mudar são mm / dd e mm / dd H: M.

@daniellee Para dd.mm. . dd/mm yyyy às vezes é visto sendo usado por pessoas mais velhas com background sueco, mas simplesmente dd/mm não é claro neste contexto, pois não há como ver em que ordem dia e mês estão lá. Usar dd/mm ainda seria muito melhor do que o estado atual se a localização completa não estiver facilmente disponível.

@calmjm obrigado - isso respondeu minha pergunta. Vou adicionar uma terceira opção. Pode haver outros formatos para outros países, mas acho que 3 é um bom começo e cobre muitos países.

A razão para usar o formato ligeiramente estranho de mês / dia (ou dia / mês) é para economizar espaço. Eu experimentei usar mmm-dd (fevereiro-12), mas ocupa muito espaço em painéis de tamanhos menores.

A implementação será introduzir uma configuração por usuário, com 4 opções: navegador, mm/dd , dd/mm e dd.mm. padrão é usar a localidade do seu navegador (com base no primeiro idioma do navegador em suas configurações).

Outra opção potencial é dd.mm (sem o ponto no final), que é o formato para países como a Polônia e a Ucrânia.

@daniellee, isso soa como um bom caminho a seguir.

@daniellee Acabei de encontrar este tópico enquanto procurava como formatar datas corretamente no Grafana. :) O próximo dd.mm. é o mais importante pra mim (Finn), obrigado por isso! Mas enquanto você está fazendo isso, você pode mudar também o aaaa / mm? Embora seja compreensível como é, ainda parece estranho. Seria preferível mm / aaaa ou "mmm aaaa".

Além disso, apenas um comentário lateral. Para nós, o delimitador correto entre minutos e horas também é o ponto. Mas não acho que haja muita demanda para mudar isso, já que não é tão fácil ver se "02.02" é hora ou data (é hora, o ponto final faltando revela isso). Claro que seria melhor se ele também pudesse ser configurado.

+1

@hraftery

Isso deve funcionar, executado a partir da linha de comando em seu servidor: 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}
Em seguida, basta atualizar a página Grafana do seu navegador.

Não consegui localizar esses arquivos (mas estou usando a versão 5.0.4).

@andreasloe mmm, parece que mudou.

/usr/share/grafana/public/build/app.*.js parecia promissor, mas mudá-lo não fez nenhuma diferença para mim ...

@daniellee (ou qualquer desenvolvedor Grafana): existe alguma maneira da comunidade influenciar a priorização desse recurso (localizar formato de hora)? Por exemplo, abrir um https://www.bountysource.com/ (ou equivalente) ajudaria? Obrigado!

@daniellee
Que tal usar toLocaleDateString com navigator.language como parâmetro?

['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

04/06/2018 04/06/2018 é realmente confuso.

refs:
https://norbertlindenberg.com/2012/12/ecmascript-internationalization-api/#DateTimeFormat
https://caniuse.com/#feat = internacionalização

+1
A melhor implementação provavelmente seria usar as unidades relevantes para o idioma (por exemplo, en-GB = dd / mm / aa e en-US = mm / dd / aa etc.), no entanto, dando-nos uma caixa para digitar nossa própria formatação no A página de eixos seria a mais flexível e também poderia suportar as opções mais obscuras para intervalos de tempo maiores, como apenas meses ou, no outro extremo, minutos apenas nos eixos.

@hraftery
Infelizmente, para aplicar as mudanças você precisa recompilar o grafana do código-fonte ...
Para alterar localmente o formato de data ao longo do eixo X:

1. Altere o modelo de retorno na função time_format () em ./public/app/plugins/panel/graph/graph.ts
   if (secPerTick <= 80000) {return '%d.%m.%Y %H:%M';}
2. Se você quiser exibir dois dígitos no dia e no mês, adicione zero no caso de troca "d" e "m" na função formatDate () em ./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. Recompile o Grafana: https://github.com/grafana/grafana/blob/master/README.md

@luxnlex, você sabe como construir o contêiner do docker após a recompilação? https://github.com/grafana/grafana-docker parece ir de versões tagges que não temos neste estágio.

Eu ficaria feliz em fornecer e atualizar este contêiner enquanto a equipe da grafana insiste em this is quite a small thing e It is only noticeable if you are zoomed out . Olhando para o número de respostas aqui, parece que não é para o público;)

+1
Vejo o Grafana como um software de visualização de dados de séries temporais e um dos melhores em sua classe, senão o melhor.
Assim, os timestamps na tela são essenciais e centrais para consumir os dados visualizados e para manter a ótima UX.
Muitas pessoas, empresas e organizações estão usando o Grafana em todo o mundo, fora dos Estados Unidos.
Permita a configuração fácil baseada na IU como os carimbos de data / hora são mostrados em diferentes culturas. Mesmo a configuração específica da instância do Grafana seria ótimo para começar, se isso não pudesse ser específico do painel, gráfico ou cliente do navegador.
Na minha opinião, este não é apenas um recurso normal ausente, mas um dos principais recursos que os usuários implicitamente esperam e presumem ter neste tipo de software excelente (!).

olá @torkelo Não sei mais a quem perguntar :-) Seria possível para a equipe da Grafana nos dizer aos usuários não americanos felizes um ETA para este recurso? Obrigado!

Eu só posso acrescentar - embora isso já tenha sido dito antes - que este é o único e mais confuso "recurso" do Grafana. Sempre que olho em qualquer gráfico, começo a coçar a cabeça e tento descobrir que intervalo de tempo estou realmente vendo como totalmente desconhecido ...

Desculpe pelo spam, mas tinha que ser dito. Acredito que não estou dizendo muito que, para usuários de fora dos EUA, esse seria facilmente o principal requisito.

Por que está demorando tanto nesse assunto? Eu simplesmente não consigo imaginar que isso seja tão complicado ...

Eu acho que a comunidade vai precisar de um pouco de código ... o que é muito difícil devido à natureza como o datetime é codificado atualmente ...

@DerKnerd havia uma solução simples (# 13429), mas não achamos que fosse bom o suficiente. Os problemas de data tornam-se difíceis quando você deseja resolvê-los de forma abrangente.

Este problema foi recentemente apresentado em uma apresentação interna sobre aumento de escopo. O caminho a seguir é um documento de design. Se alguém da comunidade quiser ser voluntário, inscreva-se em #grafana-dev no slack.raintank.io e entre em contato comigo.

@davkal obrigado por apontar para # 13429. Na verdade, para mim, que não sou dos EUA, essa correção é boa o suficiente e uma grande melhoria. Talvez essa correção possa ser feita no estado em que se encontra e o documento de design ser feito em paralelo?

@ marco-m o ponto fixo desse PR é o campo de preferência monthDate. Poderíamos contornar isso se alterássemos as configurações de data para "padrão" (ou seja, como estão agora, datas nos EUA) ou "navegador" (localizado por localidade do navegador). A lista suspensa teria apenas essas duas opções. Os navegadores dos seus usuários suportam Date.prototype.toLocaleDateString e eles teriam a localidade que você deseja que tenham?

@davkal estamos usando as versões mais recentes do Mozilla e do Chrome, e podemos atualizar para qualquer coisa se isso nos der controle sobre a renderização de data :-) E sim, podemos definir nos navegadores a localidade que pretendemos que eles tenham. Se bem entendi, sugiro escolher o que é "melhor" do ponto de vista do produto Grafana entre "padrão" ou "navegador"; teremos o maior prazer em nos adaptar à sua escolha.

@davkal Estou lutando para ver como o manuseio de datas ambíguas pode ser considerado aumento de escopo - esta é uma fonte significativa de confusão (especialmente para usuários não americanos, embora eu argumente que datas ambíguas nunca deveriam ser aceitáveis).

Dito isso, uma abordagem baseada na localidade do navegador pode ser uma opção, embora isso produza problemas para coisas como alertas? Suspeito que essa configuração realmente precisa ser persistida e consultada por usuário / por renderização. A abordagem strftime / moment.js parece uma resposta mais abrangente e imagino que haja tabelas de localidade pré-preenchidas disponíveis que podem produzir algumas predefinições para a IU.

Em relação às preferências baseadas no navegador: esteja avisado que as pessoas que trabalham internacionalmente podem escolher usar um navegador baseado em inglês, instalar (ou são forçadas a instalar) o dos EUA e ainda obter mm.dd.yyyy.

Para uma solução de curto prazo, isso ainda é bom, mas o paralelo com os estados @ marco-m deve ser um documento completo sobre a implementação da localização verdadeira com a preferência do usuário.

Obrigado por todos os comentários. Pessoalmente, eu tentaria evitar um campo de entrada adequado com um mapeamento completo.
Não tenho certeza de como o alerta é afetado, mas a renderização do servidor precisaria que a localidade do usuário passasse um parâmetro de URL (caso contrário, usaria a localidade de phantomjs). As renderizações de imagens baseadas no Slack também precisariam decidir sobre uma localidade a ser passada como um parâmetro de URL.

Replete o mapeamento: deve ser por servidor grafana, por organização, por equipe, por usuário?

@davkal escreveu:

Eu tentaria evitar um campo de entrada adequado com um mapeamento completo

Você pode descrever o que você quer dizer com isso? Eu direi que os usuários às vezes têm preferências particulares quando se trata de exibição de localidade, conforme evidenciado pelos relatórios de bug resultantes da recente implementação rígida de localidade do QT.

Eu acredito que tem que ser uma configuração por usuário, para dar suporte a equipes multirregionais, talvez com um padrão em um ou mais dos níveis superiores.

Eu realmente prefiro um campo de entrada para que as pessoas possam definir o que quiserem.
Ter que definir minha localidade para algum outro lugar para obter o formato de data que desejo
sempre termina em efeitos colaterais indesejados e frustração.

Ter um formato padrão para todo o servidor e permitir que os usuários substituam isso torna
o mais sentido para mim.
Dessa forma, a renderização do servidor e as pessoas que não estão logadas obtêm o servidor
padrão, enquanto os usuários individuais podem definir seus próprios formatos, se necessário.
Eu não uso orgs, mas pode fazer sentido usar lá também?

Na segunda-feira, 4 de março de 2019 às 09:19, David [email protected] escreveu:

Obrigado por todos os comentários. Pessoalmente, eu tentaria evitar uma entrada adequada
campo com um mapeamento completo.
Não tenho certeza de como o alerta é afetado, mas a renderização do servidor precisaria do
localidade do usuário para ser passado um parâmetro de URL (caso contrário, ele usaria phantomjs '
localidade). As renderizações de imagens baseadas no Slack precisariam decidir em uma localidade a ser
passado como um parâmetro de URL também.

Replete o mapeamento: deve ser por servidor grafana, por organização, por equipe,
por usuário?

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/grafana/grafana/issues/1459#issuecomment-469268689 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ABJyGlmAy9ebfDPryZGyVdffLReqBRp8ks5vTSuNgaJpZM4DelGY
.

Exemplo para um mapeamento completo: https://github.com/grafana/grafana/pull/13429#issuecomment -430272485

Exemplo para um mapeamento completo: # 13429 (comentário)

Suspeito que seja inevitável ter algum tipo de mapeamento como esse exposto.

A todas as pessoas que comentam aqui pedindo mais e mais: essa edição está aberta desde fevereiro de 2015. @davkal já fez um PR que, embora não seja perfeito, é uma GRANDE melhoria em comparação com, bem, o nada que temos agora. Para mim, parece mais produtivo ajudar esse PR a se fundir, como ponto de partida, ao invés de drenar de @davkal a energia que ele tinha para tornar isso uma realidade. Meus 2 centavos.

Se alguém não se preocupa com uma GUI extravagante ou suporte a navegador / região automagic, é possível corrigir o tempo de execução da versão 6 atual?

@bassebaba sim, você pode. Na pasta raiz está um público que contém uma construção de diretório. Lá está um arquivo app.<weird stamp>.js , procure por time_format e então você pode substituir o formato.

Por acaso você conhece o diretório se estou executando grafana em um raspberry (Raspbian GNU / Linux 8, Linux versão 4.14.34-v7 + (dc4 @ dc4-XPS13-9333) (gcc versão 4.9.3 (crosstool-NG crosstool- ng-1.22.0-88-g8460611)) # 1110 SMP Seg 16 de abril 15:18:51 BST 2018)?

Sim, é este caminho: /usr/share/grafana/public/build/app.e16403019d0332233699.js talvez a parte entre o aplicativo. e .js é diferente.

Obrigado! BTW, o nome do arquivo é app.469095018b321ef1da7c.js

Devo incomodá-lo novamente. Encontrei a função e já mudei para

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 "} retorna"% H:% M "}, t} ();

mas sem sucesso. Eu também reiniciei o servidor e ele diz

`● grafana-server.service - instância Grafana
Carregado: carregado (/usr/lib/systemd/system/grafana-server.service; habilitado)
Ativo: ativo (em execução) desde Di 2019-03-05 19:52:28 CET; 3min 39s atrás
Docs: http://docs.grafana.org
PID principal: 1795 (grafana-servidor)
CGroup: /system.slice/grafana-server.service
└─1795 / usr / sbin / grafana-server --config = / etc / grafana / grafana.ini --pidfile = / var / run / grafana / grafana-server.pid --packaging = ...

Mär 05 19:52:28 FHEM grafana-server [1795]: t = 2019-03-05T19: 52: 28 + 0100 lvl = info msg = "Inicializando HooksService" logger = servidor
Mär 05 19:52:28 FHEM grafana-server [1795]: t = 2019-03-05T19: 52: 28 + 0100 lvl = info msg = "Inicializando InternalMetricsService" logger = servidor
Mär 05 19:52:28 FHEM grafana-server [1795]: t = 2019-03-05T19: 52: 28 + 0100 lvl = info msg = "Inicializando CleanUpService" logger = servidor
Mär 05 19:52:28 FHEM grafana-server [1795]: t = 2019-03-05T19: 52: 28 + 0100 lvl = info msg = "Inicializando NotificationService" logger = servidor
Mär 05 19:52:28 FHEM grafana-server [1795]: t = 2019-03-05T19: 52: 28 + 0100 lvl = info msg = "Inicializando ProvisioningService" logger = servidor
Mär 05 19:52:28 FHEM grafana-server [1795]: t = 2019-03-05T19: 52: 28 + 0100 lvl = info msg = "Inicializando PluginManager" logger = servidor
Mär 05 19:52:28 FHEM grafana-server [1795]: t = 2019-03-05T19: 52: 28 + 0100 lvl = info msg = "Iniciando pesquisa de plug-in" logger = plug-ins
Mär 05 19:52:29 FHEM grafana-server [1795]: t = 2019-03-05T19: 52: 29 + 0100 lvl = info msg = "Inicializando TracingService" logger = servidor
Mär 05 19:52:29 FHEM grafana-server [1795]: t = 2019-03-05T19: 52: 29 + 0100 lvl = info msg = "Initializing Stream Manager"
Mär 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 =
Dica: algumas linhas foram reticuladas, use -l para mostrar por completo.
`

Aqui está uma captura de tela

@andreasloe, seria possível encontrar outro lugar para pedir sua ajuda específica? Ainda tenho esperança de que este tíquete seja fechado conforme corrigido no Grafana. Obrigado :-)

@andreasloe não tenho certeza. Talvez você use uma versão mais antiga do que eu. Mas como @ marco-m disse, talvez faça uma pergunta no Stackoverflow ou no reddit. Alguém lá certamente pode ajudá-lo: ligeiramente_smiling_face:

Ping @torkelo @daniellee Eu percebi que já levantei a bandeira da negligência da comunidade antes (https://github.com/grafana/grafana-plugin-repository/issues/332), mas isso ainda é o pior recurso ausente no Grafana, agora na v6.3! Tem 4 anos. Nós, fora dos Estados Unidos, não buscamos uma solução abrangente. Por enquanto, provavelmente ficaríamos totalmente felizes com qualquer melhoria já feita em relação ao nada de 4 anos.

Por favor, dê uma outra olhada no PR existente ou solução melhor e nos ajude. Eu não sou um cara frontend, mas qualquer coisa com que eu possa contribuir, por favor me avise.

Para ser um pouco mais preciso, _como_ é importante esta solicitação é que fiz uma verificação rápida de estatísticas usando a API do GH para este repo:

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

Principais pedidos:

• # 6557 (126 comentários)
• # 1959 (108 comentários)
• # 6983 (104 comentários)
• # 3752 (84 comentários)

Esta solicitação aqui tem 97 (!) Comentários e, portanto, está classificada em # 4. Não está visível nesta lista porque não está marcado como type/feature-request .

Se eu executar novamente a análise sem filtrar por tag, ela aparecerá entre as 4 primeiras:

• # 6557 (126 comentários)
• # 1959 (108 comentários)
• # 6983 (104 comentários)
• # 1459 (97 comentários)

Isso é evidência suficiente de que este problema não é "uma coisa pequena"?

Tendo trabalhado com flot antes, ficaria feliz em apresentar uma proposta de como isso ficaria em uma versão básica, visto que podemos obter suporte para a equipe central para realmente implementá-lo. Atualização: dispensa pois o PR aberto já conta com uma boa parte.

Sim, isso é loucura. Eu nem mesmo estou atualizando o grafana regularmente, já que tenho que descobrir como “hackear” a exibição do tempo novamente.
(Ainda estou na v6: P)

Eu tenho alguns planos vagos de automatizá-lo com script bash em uma imagem do Docker, que posso então reconstruir todas as atualizações, mas essa é apenas uma maneira maluca de consertar esse recurso ausente.

Estou pesquisando https://github.com/grafana/grafana/pull/13429 agora. Vou tentar reaplicar ao mestre atual. Está além da minha zona de conforto, mas parece estar praticamente pronto.

Nada disso vai ajudar, a menos que a equipe principal chegue ao seu pedido de recurso de 4ª maior classificação ...

Uau! Isso é uma loucura!

Acabei de passar um momento significativo procurando uma maneira de alterar o formato de data do eixo x nas configurações de grafana. Este é um recurso tão básico e necessário que não me ocorreu que ainda não pudesse ser implementado.

Eu ficaria muito feliz se você pudesse tocar no assunto em breve :)

Copiado de # 18659:

Lembrete rápido de que # 13429 não teve sucesso porque apenas o formato do mês foi abordado. ...
O primeiro passo deve ser adicionar um comentário em # 1459 sobre suas intenções, então junte-se ao público em slack.grafana.com.

@davcal não ficou

Da perspectiva do usuário problemático, eu realmente não me importaria. Um formulário simples poderia combinar todas as configurações como @torkelo sugerido em uma lista suspensa com padrões razoáveis ​​para os EUA e países selecionados. US pode parecer uma versão concatenada de:
...
Isso pode terminar no config json, conforme sugerido por @torkelo. Qualquer coisa que não comece com um P seria o formato padrão. Uma entrada "customizada" na lista suspensa permitiria especificar minha própria string de formato, não importa se eu preciso construir essa interface de usuário grafana externa, pois é realmente uma tarefa única e PRs para padrões adicionais seriam facilmente feitos a partir daí.

Embora uma versão polida fosse ótima, depois de mais de 4 anos de espera, eu (e provavelmente a maioria dos usuários) ficaria feliz em ter qualquer coisa.

Portanto, antes de fazer qualquer outra coisa (como escrever um documento de design), eu preciso estar convencido de que Grafana está, mesmo que remotamente interessado, em realmente se envolver na discussão e avançar com uma das solicitações de recurso de melhor classificação :(

Eu também estou frustrado. Para deixar claro, ao demonstrar nossas pilhas de serviço usando Grafana para visualização, sempre tenho que desculpar para nossos clientes, que estão perguntando sobre o formato de data, que Grafana (caso contrário, tão bom) não sabe e não pode ser configurado para mostrar carimbos de data / hora como os clientes desejam. Isso está arruinando todas as demonstrações iniciais, já que você sempre tem que explicar por que esse recurso de front-end e muito visível não está funcionando. É um recurso básico e não está funcionando, pois não está dando o que os clientes desejam. Por favor, comece a cuidar deste problema, por favor.

1, realmente frustrante, não consigo obter formatos de data internacionais na série X.

Eu ficaria feliz e apoiaria com uma abordagem em torno de um mapeamento de formato, com padrões para localidades populares. No entanto, estamos procurando alguém na comunidade para assumir esse esforço. Estou à disposição para qualquer orientação.

Aqui está um esboço do trabalho necessário:

• você pode usar # 18659 como ponto de partida, obrigado @andig
• especifique um mapeamento de data que tenha formatos para várias resoluções de tempo
• potencialmente reescrever monthDayFormat para armazenar o mapeamento selecionado
• adicione lógica para usar o mapeamento no formatador de data do gráfico
• adicione mapeamentos para localidades populares em uma lista suspensa
• fornecer uma opção personalizada na lista suspensa para fornecer o próprio mapeamento
• adicionar tratamento de erros em torno do mapeamento personalizado
• escrever testes para validação de mapeamento
• documentação de atualização

Por favor, entre em contato comigo ou com @torkelo em nossa folga pública se você quiser fazer isso. Antes de iniciar qualquer trabalho, certifique-se de postar aqui também. Veja também nossas diretrizes para contribuições .

Ótimo ver esse movimento!

especifique um mapeamento de data que tenha formatos para várias resoluções de tempo

Acho que o que podemos fazer aqui é criar uma lista abrangente de formatos de data. No entanto, devemos primeiro esclarecer os parâmetros.
O código atual depende do comprimento do tique e do intervalo do gráfico para escolher a formatação. O flutuador original usa apenas o comprimento do tique e verifica se o comprimento está abaixo dos intervalos fixos (minuto, dia, mês, ano). Se quisermos manter isso flexível, eu proporia:

• tornar os intervalos configuráveis
• use a notação ISO (compatível com Go e momentjs)
• verifique o comprimento do tick em relação aos intervalos, se abaixo do intervalo você tem o seu formato
• deve haver localidades pré-configuradas e a capacidade de usar seu próprio formato

Isso exigiria algo como uma tabela de mapeamento, conforme sugerido em https://github.com/grafana/grafana/pull/13429. Os EUA podem ser parecidos com isto (é necessário verificar novamente as strings de formato de momento). Lembre-se de que as durações seriam o limite superior do tamanho do tique:

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

A Alemanha seria assim:

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

Reino Unido (suposição) seria assim (formato de 12 horas):

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

A formatação pode vir em arquivo de configuração ou baseada em IU. Para baseado em IU, pode fazer sentido ter padrões para localidades populares (pelo menos EUA) e permitir configuração de texto livre baseada no usuário. Este último poderia ser apenas:

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

Essa discussão é um pouco insana. Ele está mostrando, em público, uma desconexão entre alguns dos principais desenvolvedores da grafana e alguns de seus usuários.

Como um usuário europeu (e desenvolvedor, mas não grafana dev), eu certamente gostaria desse recurso. Também estou ciente de que a grafana é (até onde sei) desenvolvida principalmente por pessoas como voluntários em seu tempo livre e, em qualquer caso, todos os projetos de desenvolvimento têm que ser priorizados.

Talvez as pessoas que gostariam de contribuir para que esse recurso aconteça pudessem se identificar. Foi apontado que os desenvolvedores de grafana se comunicam com folga, então esse pode ser o lugar certo para fazer isso. E então, para que essas pessoas permaneçam cientes de que todos os projetos têm procedimentos e que se espera que cumpram o que quer que isso signifique aqui.

E talvez um grafana dev possa se identificar como um mentor paciente para ajudar essas pessoas a realizar a tarefa de colocar esse recurso no branch master. Acho que isso aconteceu com @davkal . (Kudos.)

@JeffAbrahamson

Como um usuário europeu (e desenvolvedor, mas não grafana dev), eu certamente gostaria desse recurso. Também estou ciente de que a grafana é (até onde sei) desenvolvida principalmente por pessoas como voluntários em seu tempo livre e, em qualquer caso, todos os projetos de desenvolvimento têm que ser priorizados.

Exatamente. Estou desconfortável com a suposição de direito em _alguns_ dos comentários, esquecendo que Grafana é _gratuito_ e _ fonte aberta_, como mencionei um pouco acima em https://github.com/grafana/grafana/issues/1459#issuecomment -469317707.

Só quero agradecer mais uma vez a @davkal por seus esforços e por sua generosidade.

Se meu comentário foi ofensivo, peço desculpas sinceramente. Estou muito grato pelo trabalho de todos neste projeto.

@andig - Sua suposição sobre o formato de data do Reino Unido parece correta, se essa for uma boa solução.

Uma alternativa, se me permitem ousar - e não conhecendo nenhum dos detalhes internos, não sei se esta é uma sugestão válida, então descarte se não for: Uma caixa simples na página Estilo de um gráfico que permite ao usuário cole em um formato de data de substituição para a escala X. Talvez usando o formato de expansão de string comum usado em outros lugares, como em php; https://www.php.net/manual/en/function.date.php poderia fornecer uma interpretação de forma livre completa e ajustar todos os casos de uso por gráfico, em vez de aplicar um formato para todos. (Em uso, às vezes tenho o desejo de mostrar o dia da semana em vez de uma data, por exemplo)

Algo talvez:

Substituir formato de data X []

Que, se definido, expandiria tokens como
% D% d,% M até segunda-feira, 12 de setembro

% D% G:% H a seg 13:45

Meta: apenas para esclarecer o desenvolvimento do Grafana é liderado pela equipe do Grafana Labs de cerca de 25 desenvolvedores (incluindo eu). Mas se você considerar o tamanho do software, o tamanho da equipe é muito baixo, e o software não seria tão útil sem todas as contribuições da comunidade. Nosso desafio para recursos como este aqui, que não são urgentes, mas importantes, gostaríamos de encontrar uma maneira de permitir que a comunidade desenvolva o recurso. Temos muitas histórias de sucesso de contribuições individuais importantes e ficaria mais do que feliz em orientá-lo nesse processo ([email protected]).

Uma caixa simples na página Estilo de um gráfico que permite ao usuário colar em um formato de data de substituição para a escala X.

Sou menos fã, pois mudar isso em todo o sistema será um fardo contínuo quando novos painéis forem adicionados à organização do usuário. Até agora, ainda estou defendendo a abordagem apresentada acima.

Para fins de transparência: Eu fiz o rebase o mais longe que pude, sem a) capacidade de testar (consulte pr para problemas encontrados) eb) conhecimento profundo de desenvolvimento de front-end. Lamento dizer que você vai ter que me excluir.

+1, preferimos qualquer coisa menos o formato MMDD :)

Como posso personalizar o formato de data e hora em uma série em um gráfico? Diga remover a hora, alterar o formato da data ou adicionar segundos?

+1

A correção acima não funciona para mim com Grafana 6.7.1 Mas:

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

NB Estou executando isso em um contêiner docker, mas caso contrário, não sugiro executá-lo sem fazer backup dos arquivos em / usr / share / grafana / public primeiro.

Mas funciona para mim.

Para substituir o ponto de entrada padrão em docker-compose:
ponto de entrada: bash -c "find / usr / share / grafana / public -tipo f -exec sed -i 's @% m /% d @% d /% m @ g ' {} + && /run.sh"

Obrigado, para aqueles que querem a versão alemã (1.4 em vez de 1/4), então a seguinte?
bash -c "find / usr / share / grafana / public -tipo f -exec sed -i 's @% m /% d @% d.% m @ g ' {} +"
Ou preciso de um caractere especial antes do ponto?

apoglogias, não estou funcionando, voltarei se encontrar uma solução,

A correção acima não funciona para mim com Grafana 6.7.1 Mas:

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

NB Estou executando isso em um contêiner docker, mas caso contrário, não sugiro executá-lo sem fazer backup dos arquivos em / usr / share / grafana / public primeiro.

Mas funciona para mim.

Para substituir o ponto de entrada padrão em docker-compose:
ponto de entrada: bash -c "find / usr / share / grafana / public -tipo f -exec sed -i 's @% m /% d @% d /% m @ g ' {} + && /run.sh"

Isso não é bom. Mais um ano se passou, o Grafana está se aproximando da versão 7, a localização é considerada "uma coisa pequena" apesar de ser a 4ª solicitação de recurso com melhor classificação e aqui estamos hackeando os binários ...

Sim, gostaria de falar com o product owner. Por que esta solicitação de recurso não está no topo da lista? Alta demanda, possível, longa história, aumento nas vendas / usabilidade ... o que mais um pedido de compra precisa?

@davkal, você poderia gentilmente marcar isso como type/feature-request acordo com https://github.com/grafana/grafana/issues/1459#issuecomment -523313533 para que pelo menos apareça em suas priorizações?

Sou um dos proprietários do produto e listei meu e-mail e a folga pública como formas de entrar em contato. Ninguém me contatou.

Nosso convite para contribuir ainda está aberto. As etapas são apresentadas acima. Estamos amadurecendo como uma organização de engenharia, portanto, para esse empreendimento, a parte que gostaria de trabalhar nisso deve começar um documento de design. Veja este como exemplo .

Sou um dos proprietários do produto e listei meu e-mail e a folga pública como formas de entrar em contato. Ninguém me contatou.

@davkal Não sei como reagir, mas o que você está escrevendo me deixa triste:

• Eu pessoalmente tentei destacar a importância desta solicitação https://github.com/grafana/grafana/issues/1459#issuecomment -523313533
• tentou encaminhar a especificação https://github.com/grafana/grafana/issues/1459#issuecomment -528817275
• Eu tentei - embora com habilidade limitada - empurrar um PR abandonado ainda mais (https://github.com/grafana/grafana/pull/18659) e pedi ajuda https://github.com/grafana/grafana / pull / 18659 # issuecomment -523422092
• foi dito que deveria ser abandonado:

Não indo em frente com isso, consulte também # 13429

• foi informado em https://github.com/grafana/grafana/pull/13429 que:
  Não indo em frente com isso, tentarei novamente com uma abordagem mais abrangente.

E como você está dizendo:

Ninguém me contatou.

Não vou dizer mais nada, mas não me sinto apreciado agora.

Seu esforço foi certamente apreciado, @andig e você tentou avançar no assunto. Meu ponto é que não houve nenhuma outra discussão além da nossa (aquela acima em setembro de 2019).

Para esclarecer novamente: a localização de formatos de gráfico faz muito sentido e está no roteiro. Talvez possamos até chegar a isso neste verão, mas não confie em nós para isso, os roteiros podem mudar. Se esse recurso for útil para você, sinta-se à vontade para contribuir e fazer com que isso aconteça mais cedo.

Espero que chegue logo, grafana carece de alguns recursos básicos como este (formatar data com configurações do usuário ...)

Parece que os parâmetros de consulta de url timeRange do stackdriver esperam tempos formatados em ISO 8601 e não carimbos de data / hora Unix. Ter a hora formatada por ISO para isso desbloquearia a vinculação ao stackdriver dos painéis (com a hora atual). Obrigado por todo o trabalho duro!

Alguém pode fornecer uma solução SED / patch para o Grafana 7? (m / d) -> (d / m)

Um pouco de RP para melhorar as coisas. https://github.com/grafana/grafana/pull/25602.
Sugere o uso de formato de navegador local para painel gráfico.

Parece que uma opção virá em breve, mas para aqueles que procuram uma solução rápida:

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

Funciona no Grafana v7

+1, não posso acreditar que uma coisa tão trivial está em discussão há mais de 5 anos
os usuários corporativos do Grafana também sofrem do mesmo problema?

Ha ha. 5 anos se passaram. É vergonha.

Por favor, priorize consertar isso. Gráficos com formatação mm / dd são tão inúteis.

Eu não me importo com a solução perfeita de permitir que cada usuário escolha uma formatação individual, uma única configuração de sistema para formatação de data está ok, contanto que eu seja capaz de evitar a exposição a essa horrível anormalidade de formatação de data.

As opções de formatação de data do sistema acabaram de ser mescladas https://github.com/grafana/grafana/pull/27216

Adiciona essas configurações 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

Por favor, teste e dê feedback. Planeje adicionar configurações de nível organizacional para isso também em uma versão futura. O use_browser_locale ainda tem alguns problemas para corrigir (detectar 12 vs 24 horas). Uma opção first_day_of_week também pode ser uma boa adição a isso.

Obrigado @torkelo muito apreciado!

Aqui está um exemplo

Config:

[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

Que notícia maravilhosa, muito obrigado! Reiniciei o grafana mas o novo formato não apareceu. Qual versão devo instalar - você pode me indicar um site que explique isso?

Crie noturno ou espere pelo 7.2 beta (muito em breve)

Crie noturno ou espere pelo 7.2 beta (muito em breve)

Com que frequência a marca mestre no dockerhub é atualizada? Já tem dois dias, seria possível acioná-lo com mais frequência?

Boa, @torkelo - o seguinte está funcionando bem na imagem do docker grafana:7.3.5 (trecho 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

No entanto, definir GF_DATE_FORMATS_USE_BROWSER_LOCALE=true não funcionou para mim aqui na Austrália, usando o Firefox em um mac - os formatos de data curta permaneceram no formato MM / DD específico dos EUA.