yes, better options for this should be added. Not sure what the best way is, think there even might be a PR for this that was submitted a long time ago which I have not had time to review yet.

Cool, thanks!
Now, I rebuilt grafana with hardcoded european format in my project =)

This would be useful as European date format is not in the same order (day/month/year) dates are actually confusing

+1

+1

+1

For anyone else that wants to fix this;
I use this for my solaris build.

Tries public_gen incase grunt has already been run.

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

!/bin/bash

set -e

patch(){
echo -e "Attempting to patch into;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
patch
GRAPHJSFOLDER=$GRAFANAROOT/public_gen/app/panels/graph
patch
```

+1

+1

+1 on this, forcing US locale MM/dd in graphs isn't ideal. Possibly helped by the locales introduced with #5517?

+1

+1, this is currently blocking adaption in our company

@tokudan Hey, this is what we did in our solution; https://github.com/grafana/grafana/issues/1459#issuecomment-162446127

It would be wonderful if this could take the actual browser localisation into account or if users could at least configure it manually. Forcing everyone to use US style dates is really quite suboptimal.

+1

+1

It would be great when the date could be generally customized. Example:
Instead of having
2016-11-21 21:19:00
I'd like to see the weekday as well as a short date (german format here):
Mo, 21.11., 21:19

@RyanCarrier any idea how to make this modification without building from source? I found the equivalent file in my Ubuntu installation (from deb package) here:

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

Alas, modifying that file, restarting grafana-server and refreshing the browser does not pick up the change. I spotted this minified version:

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

and thought I was on to a winner, but alas, same result. Do you know if there's another compilation output that grafana uses that would explain why modifying these files doesn't make a difference?

Hey dude if the script I wrote previously doesn't work and you're stilling having trouble, respond back and I'll have a look when I have some time back home (Probably the 2nd or 3rd).

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

Oh sorry I didn't realise from deb package. I'll have to have a look at home and have a go on my server. Bump me if I don't respond by the 3rd. :)

Bumping @RyanCarrier - haven't been to figure this one out. Suspect it's something simple, but I can't get Grafana to pick up any changes I make to graph.ts (without compiling from source, which I'd prefer to avoid if possible).

they have changed stuffa round since I last played, and I don't have a environment like I did back then. But I've found %m/%d in a few files; to keep you updated.

public/app/app_bundle.js:13
public/app/boot.js:18
public/app/boot.fnsdmjkfnasjk.js
the rest are in
public/app/plugins/panel/graph

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

Hey so the it's the weird boot.123456.js in /usr/share/grafana/public/app.

Just to be safe I would change it in boot.js too, I assume it gets built when you install it?

just run that sed command I made just remember your numbers will be different but;

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

then just refresh the page (ctrl shift r) probs works with regular refresh. But whatever.

Sorrry it took me so long I completely forgot.

the command just replaces all %m/%d with %d/%m

I would also run it on the other files also, for incase they are joined together during recompile or update or something.

That did it! Regular refresh was enough. The other files you mention are also present and contain the string.

Bit mysterious. Suspect that's going to be useful knowledge for other issues that crop up. Thanks a lot!

Is there a way of changing the date format through the Grafana GUI or settings? I can see some chatter about making changes to source files, which i'd rather not do :)

@leinad13 Not at present, hence the resort to source files. Not ideal, but actually pretty easy.

This should do it, executed from the command line on your server:

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}

Then just refresh your browser's Grafana page.

+1 also for me

Ok, stumbled over this when comparing Grafana to Kibana. Unfortunately, not supporting locale settings (date / time / number formats etc) is is a show stopper for Grafana in professional environments (simply can't deliver a project with a wrong locale). Would be really good if this gets fixed with prio (and without nasty source patching). @torkelo

+1

+1

+1

In my case I'm having issues with dates on X axis sometimes showing only time part, sometimes with date (US format, EU here) and I can't control it in any predictable way. Somehow related to #3591

+1

+1

+1

At a second glance the flot code (jquery) is used. In there, you have formatting options, if they are passed. See jquery.flot.time.js
For global use good localization is crucial. And please do not stick with options automagically taken from browser settings. Using a US based language does not mean I want to have the non conformant US localization...

+1

+1, as a workaround I use now 23h views to disable showing weird dates in the main use cases.

+1

+1

We would be very appreciated if you prioritise this issue. It is really confusing for European users. Thanks a lot!

+1

+1

+1

+1

I can't roll this out in UK with US date formats, because people are guaranteed to mis-read the date.

Just to be clear about this - USA is basically the only country on the planet that uses M/D/Y date format. The rest of the world find that format very confusing. See https://en.wikipedia.org/wiki/Date_format_by_country

By not supporting local date formats, you're effectively telling anyone outside of USA that they shouldn't use Grafana.

At least use, say, ISO 8601 as default if it can't be made configurable. That should be a simple fix that can be rolled out right away.

I can't believe that this bug has been filed three years ago.

Yeah, ISO 8601 is a good short term fix.

Doesn’t appear as if Grafana has any desire or appetite to do this, I hadn’t originally noticed that this ticket was created 3 years ago!

it's not like we do not want to, but unless you haven't noticed there are about 1000 open feature requests :)

I hope you realize this is more than a FR. This is a blocker for adoption outside the USA. It seems like a decision in coding long time ago that is having nasty side affects now.

I gave you guys work arounds twice earlier in this thread. If you it's really that much of an issue for you and you can't do the work arounds for some reason. Make the change yourself. The whole point of open source is to be able to contribute and work together, not cry that these volunteers aren't doing exactly what you want.

@RyanCarrier We are all very sorry for keeping you away from your very important tasks. We are also very sorry for pushing our favorite feature over those 1000s of other FRs.
We will probably start crying at doors of the Company behind Grafana from now on: https://grafana.com/services/support

First off, this is quite a small thing. It is only noticeable if you are zoomed out and if you hover over a point you can see the whole date. I do not understand the argument that this is a blocker for adoption outside the USA. (I have used Grafana from day 1 and live in Sweden and have never even noticed this issue).

I actually had a look at this last week but it was more complicated than I thought. I did a quick spike to try and automatically figure out the month-day format per locale - both with MomentJS and with Date.prototype.toLocaleDateString().

MomentJS has no support for the month/day format per locale but toLocaleDateString might work. The problem is that it depends on your browser settings (language settings in Chrome) so that most people will get the American format anyway even if they are located in Europe.

We came to the conclusion that the only way to do it would be to add it as a configuration setting (with choices: use browser locale, or set explicitly).

P.S. @mvhconsult Grafana is very much an open source project and most releases consist mostly of features and bug fixes contributed by the Grafana community. You are not paying anything for Grafana and have never contributed any fixes or features so please try and keep the tone civil.

@daniellee With the risk of starting a real off topic discussion here, so this being the last from me. I've been involved in opensource for the last 15 years, so I do know what it is like to get all those requests that seem unimportant to you. For sure most is not visible here.
One way to get people involved and spend their precious time to look into yet another project (there is life outside Grafana), is to give them pointers how to work, and reasons why things are not picked up by the core team, together with well documented code. The way to scare people off (or even to get them "why would I even care again about this product or team") is to tell them it is nonsense, they should just dig into the source code and implement some half way patches themselves, and belittle them with telling them they moan/cry. If the policy here is that only code contributors may make requests: fine with me, then I'm off to real life again.

@mvhconsult nobody from the core team said that this feature request is nonsense. I'm on the core team and have spent time looking at how to solve it. Maybe you did not notice that I recently assigned this issue to myself? I also just wanted to point out that this is a small issue and not something that we would mark as priority 1 (it is absolutely a valid issue but it does not affect most people and even people who notice it can easily work around it).

Discussion around feature requests is fine (and encouraged) but I felt that this was uncalled for:

We will probably start crying at doors of the Company behind Grafana from now on:

which is why I asked if you can tone it down a bit. Thanks.

If you want to take this on then I am more than happy to help you get started. You can start with setting Grafana up for development: http://docs.grafana.org/project/building_from_source/

@daniellee this is definitely NOT a small thing and there is no "easy workaround" as far as I'm aware.

It is extremely common to have graphs showing more than a single day of data, e.g. previous week or month or year, and all of these graphs show dates in the MM/DD format on the axis. You don't need to mouseover anything to see these wrongly formatted dates.

It sounds like you're not experiencing the issue yourself, but surely the number of "+1" on this thread surely makes it clear that lots of people do have a problem with it.

I think most people do also appreciate the difficulties of running a popular open source project, especially when there are lots of feature requests and minimal resources. This is exactly the reason why some of us are championing this issue - we're trying to make the case that this is a big problem for a LOT of people, and it would be great if if can be addressed.

@andymadge cool, I can understand that others can have a totally different view to me and as you say lots of people have voted for it. This feature will be implemented soon as the tick formatting is wrong for most of the world and should be fixed.

Just trying to figure out the most user-friendly way to present this option. I think I will change the tick format to default to toLocaleDateString() with the first language in navigator.languages but have a config option to set the month/day (or day/month) format in the user preferences.

I have a question that maybe someone from a country with a date format that includes dots or similar (Finland, Germany or South Korea for example) can answer.

Is it ok to just have two explicit options: mm/dd or dd/mm. October 20th would be 10/20 or 20/10.

@daniellee sounds good to me.

Am I right in saying the ticks only ever show month and day, or year and month, never all 3 together?

@andymadge yes, you are right. There are different formats for the different zoom levels. Starting at the most zoomed out:

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

The ones I will be changing are mm/dd and mm/dd H:M.

@daniellee For Finnish (and German) users correct format would be dd.mm.. dd/mm yyyy is sometimes seen being used by older people with Swedish background, but plain dd/mm is unclear in this context as there is no way to see in which order day and month are there. Using dd/mm would still be much better than the current state if full localization is not easily available.

@calmjm thanks - that answered my question. I'll add a third option. There might be other formats for other countries but I think that 3 is a good start and covers a lot of countries.

The reason for using the slightly weird month/day (or day/month) format is to save space. I experimented with using mmm-dd (Feb-12) but it takes too much space in smaller sized panels.

The implementation will be to introduce a per user setting, with 4 options: browser, mm/dd, dd/mm and dd.mm. Default is to use the locale of your browser (based on the first browser language from your settings).

Another potential option is dd.mm (without the dot at the end) which is the format for countries like Poland and the Ukraine.

@daniellee that sounds like a good way forward.

@daniellee Just found this thread while searching how to format dates correctly in Grafana. :) The upcoming dd.mm. is the most important for me (Finn), thanks for that! But while you are at it, can you consider changing also the yyyy/mm? While that is understandable as it is, it still feels weird. Either mm/yyyy or "mmm yyyy" would be preferable.

Also, just a side comment. For us the correct delimeter between minutes and hours is also the dot. But I don't think there is a lot demand for changing that, since then it's not so easy to see if "02.02" is time or date (it's time, the missing end dot reveals that). Of course this would be best if it could be also configured.

+1

@hraftery

This should do it, executed from the command line on your server: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}
Then just refresh your browser's Grafana page.

I was not able to locate those files (but I am using version 5.0.4).

@andreasloe mmm, looks like it has moved.

/usr/share/grafana/public/build/app.*.js looked promising, but changing it didn't make any difference for me...

@daniellee (or any Grafana developer): is there any way for the community to influence the prioritization of this feature (localize time format) ? For example, would opening a https://www.bountysource.com/ (or equivalent) help ? Thanks!

@daniellee
How about using toLocaleDateString with navigator.language as parameter?

['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 for 2018-06-04 is really confusing.

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

+1
Best implementation would probably be using the units relevant to the language (eg. en-GB = dd/mm/yy and en-US = mm/dd/yy etc.) however giving us a box to type in our own formatting on the axes page would be the most flexible and then could also support the more obscure options for larger time frames such as months only, or at the other extreme minutes only on the axes.

@hraftery
Unfortunately that to apply the changes you need to re-compile grafana from source...
For locally change date format along the X axis:

1. Change return template in function time_format() in ./public/app/plugins/panel/graph/graph.ts
   if (secPerTick <= 80000) {return '%d.%m.%Y %H:%M';}
2. If you want display two digits in the day and month then add zero in switch case "d" and "m" in function formatDate() in ./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. Re-compile Grafana: https://github.com/grafana/grafana/blob/master/README.md

@luxnlex are you aware how to build the docker container after the recompile? https://github.com/grafana/grafana-docker seems to go from tagges versions which we don't have at this stage.

I'd be happy to provide and update this container while the grafana team keeps insisting this is quite a small thing and It is only noticeable if you are zoomed out. Looking at the number of responses here it seems it isn't for the audience ;)

+1
I see Grafana as a time series data visualization software and one of the best in its class, if not the best.
As such, on-screen time stamps are essential and central for consuming the data that is visualized and to maintain the great UX.
Lots of people, companies and organizations are using Grafana worldwide, outside of US.
Please allow easy UI-based configuration how timestamps are shown in different cultures. Even Grafana instance specific setting would be great to start with, if this cannot be Dashboard, Graph or Browser client specific.
In my mind this is not just normal missing feature, but one of those core features that users implicitly expect and assume to have in this kind of super great(!) software.

hello @torkelo I don't know who to ask anymore :-) Would it be possible for the Grafana team to tell us non-USA happy users an ETA for this feature ? Thanks!

I can only add- although this has been said before- that this is the single, most confusing "feature" of Grafana. Any time I look and any chart I start scratching my head and try to figure out what time range I'm really seeing as its entirely unfamiliar...

Sorry for the spam but it had to be said. I believe its not saying too much that for non-US users this would easily be the top requirement.

What is taking so long on this issue? I just cannot imagine that this is so complicated...

I guess the community will need to come of with a bit of code... which is pretty hard due to the nature how the datetime is coded currently...

@DerKnerd there was a simple fix (#13429), but we didn't think it was good enough. Date issues become hard when you want solve them comprehensively.

This issue recently featured in an internal presentation about scope creep. The way forward is a design doc. If anyone from the community wants to volunteer, please join #grafana-dev on slack.raintank.io and reach out to me.

@davkal thanks for pointing to #13429. Actually for me, non-USA, that fix is good enough and a great improvement. Maybe that fix could go in as-is and the design document be done in parallel ?

@marco-m the sticky point of that PR is the monthDate preference field. We could possibly get around this if we changed the date settings to be "default" (ie. how they are now, US dates) or "browser" (localized by browser locale). The dropdown would only have those two options. Do your users' browsers support Date.prototype.toLocaleDateString and would they have locale that you intend them to have?

@davkal we are using the latest versions of Mozilla and Chrome, and we can update to anything if that gives us control over the date rendering :-) And yes, we can set on the browsers the locale that we intend them to have. If I understand correctly, I would suggest to pick what is "best" from a Grafana product point of view between "default" or "browser"; we will be more than happy to adapt to your choice.

@davkal I'm struggling to see how unambiguous date handling might be considered scope creep - this is a significant source of confusion (particularly for non-US users, though I'd argue that ambiguous dates should never be acceptable).

That said, a browser-locale based approach might be an option, though does that produce issues for things like alerting? I suspect this configuration really needs to be persisted and queried per-user/per-render. The strftime/moment.js approach seems a more comprehensive answer, and I imagine there are pre-populated locale tables readily available that could produce some presets for the UI.

Regarding browser based preference: be warned that people working internationally might choose that use an English based browser, install (or are forced to install) the US one, and then still get mm.dd.yyyy.

For short term solution that is still fine, but the parallel as @marco-m states should be a full document on implementing true localization with a user preference.

Thanks for all the feedback. Personally, I'd try to avoid a proper input field with a complete mapping.
Not sure how alerting is affected, but server rendering would need the user's locale to be passed a URL param (otherwise it would use phantomjs' locale). Slack-based image renders would need to decide on a locale to be passed as a URL param as well.

Re complete mapping: should it be per grafana server, per org, per team, per user?

@davkal wrote:

I'd try to avoid a proper input field with a complete mapping

Can you describe what you mean by this? I will say that users sometimes have particular preferences when it comes to locale display, as evidenced by the bug reports resulting from QT's recent rigid locale implementation.

I believe it has to be a per-user setting, to support multi-region teams, maybe with a default at one or more of the higher levels.

I would really prefer an input field so people can set whatever they want.
Having to set my locale to some other place to get the date format I want
always ends in unintended side effects and frustration.

Having a serverwide default format, and letting users override that makes
the most sense to me.
That way server rendering and people who aren't logged in get the server
default, while individual users can set their own formats if they need.
I don't use orgs, but it might make sense to do it there as well?

On Mon, 4 Mar 2019 at 09:19, David notifications@github.com wrote:

Thanks for all the feedback. Personally, I'd try to avoid a proper input
field with a complete mapping.
Not sure how alerting is affected, but server rendering would need the
user's locale to be passed a URL param (otherwise it would use phantomjs'
locale). Slack-based image renders would need to decide on a locale to be
passed as a URL param as well.

Re complete mapping: should it be per grafana server, per org, per team,
per user?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/grafana/grafana/issues/1459#issuecomment-469268689,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABJyGlmAy9ebfDPryZGyVdffLReqBRp8ks5vTSuNgaJpZM4DelGY
.

Example for a complete mapping: https://github.com/grafana/grafana/pull/13429#issuecomment-430272485

Example for a complete mapping: #13429 (comment)

I suspect it may be unavoidable to have some sort of mapping like this exposed.

To all the people commenting here asking for more and more: this issue is open since Feb 2015. @davkal already made a PR that, although not perfect, is a HUGE improvement compared to, well, the nothing that we have now. To me it seems more productive to help that PR to be merged, as a starting point, as opposed to drain from @davkal the energy he had to make this a reality. My 2 cents.

If one don’t care about a fancy GUI or automagic browser/region support, is it possible to runtime patch the current 6 version?

@bassebaba yes you can. In the root folder is a public which contains a directory build. In there is a file app.<weird stamp>.js, search in there for time_format and then you can replace the format.

Do you happen to know the directory if I am running grafana on a raspberry (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 Mon Apr 16 15:18:51 BST 2018)?

Yeah it is this path: /usr/share/grafana/public/build/app.e16403019d0332233699.js maybe the part between app. and .js is different.

Thanks! BTW the filename is app.469095018b321ef1da7c.js

I must bother you again. I found the function and I already changed it to

t.prototype.time_format=function(t,e,n){if(e&&n&&t){var a=n-e,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}();

but to no avail. I also restarted the server and it says

`● grafana-server.service - Grafana instance
Loaded: loaded (/usr/lib/systemd/system/grafana-server.service; enabled)
Active: active (running) since Di 2019-03-05 19:52:28 CET; 3min 39s ago
Docs: http://docs.grafana.org
Main PID: 1795 (grafana-server)
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="Initializing HooksService" logger=server
Mär 05 19:52:28 FHEM grafana-server[1795]: t=2019-03-05T19:52:28+0100 lvl=info msg="Initializing InternalMetricsService" logger=server
Mär 05 19:52:28 FHEM grafana-server[1795]: t=2019-03-05T19:52:28+0100 lvl=info msg="Initializing CleanUpService" logger=server
Mär 05 19:52:28 FHEM grafana-server[1795]: t=2019-03-05T19:52:28+0100 lvl=info msg="Initializing NotificationService" logger=server
Mär 05 19:52:28 FHEM grafana-server[1795]: t=2019-03-05T19:52:28+0100 lvl=info msg="Initializing ProvisioningService" logger=server
Mär 05 19:52:28 FHEM grafana-server[1795]: t=2019-03-05T19:52:28+0100 lvl=info msg="Initializing PluginManager" logger=server
Mär 05 19:52:28 FHEM grafana-server[1795]: t=2019-03-05T19:52:28+0100 lvl=info msg="Starting plugin search" logger=plugins
Mär 05 19:52:29 FHEM grafana-server[1795]: t=2019-03-05T19:52:29+0100 lvl=info msg="Initializing TracingService" logger=server
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=
Hint: Some lines were ellipsized, use -l to show in full.
`

Here is a screenshot

@andreasloe would it be possible for you to find another place to ask for your specific help ? I still have hope for this ticket to be closed as fixed into Grafana. Thanks :-)

@andreasloe not sure. Maybe you use an older version than me. But like @marco-m said, maybe ask a question on Stackoverflow or reddit. Someone there can surely help you :slightly_smiling_face:

Ping @torkelo @daniellee I realize that I‘ve sort of raised the flag on negligence of community before (https://github.com/grafana/grafana-plugin-repository/issues/332), but this is imho still the worst missing feature in Grafana, now at v6.3! It is 4 years old. We outside the US do not seek a comprehensive solution. For time being we would probably be totally happy with any have-baked improvement over the nothingness of 4 years.

Please, have another look at the existing PR or better solution, and help us. I‘m not a frontend guy, but anything I could contribute please let me know.

To be a little more precise just _how_ important this request is I've done a quick stats check using the GH api for this repo:

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

Top requests:

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

This request here has 97(!) comments and hence ranks at #4. It is not visible in this list as it's not tagged as type/feature-request.

If I re-run the analysis without filtering by tag it shows up right in the top 4:

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

Is this enough evidence that this issue is not "a small thing"?

Having worked with flot before I'd be happy to come up with a proposal how this might look in a basic version, given we can get support for the core team for actually implementing it. Update: not necessary as the open PR already has a good part of it.

Yeap this is insane. I’m not even regularly updating grafana since I then have to figure out how to ”hack” the time display again.
(Im still on v6 :P)

I have some loose plans of automating it with bash scripting in a Docker image which I can then just rebuild every update, but thats just an crazy way of fixing this missing feature.

I'm looking into https://github.com/grafana/grafana/pull/13429 now. I'll try to reapply to current master. It is beyond my comfort zone but looks pretty much done.

None of this will help unless core team steps up to their 4th-highest ranking feature request...

Wow! This is insane!

I just spent a significant moment looking for a way to change the x-axis date format in grafana settings. This is such a basic and needed feature it didn't occurred to me it could be yet to implement.

I'd be really happy if you could bring it up shortly :)

Copied from #18659:

Quick reminder that #13429 did not succeed because only the month format was addressed. ...
First step should be to add a comment on #1459 about your intentions, then join the public slack at slack.grafana.com.

@davcal it was not transparent from the discussion that #13429 did not succeed. I did actually comment saying:

From troubled user's perspective I really wouldn't care. A simple form could just combine all settings as @torkelo suggested into a dropdown with reasonable defaults for US plus selected countries. US might look like a concatenated version of:
...
This could end in the config json as suggested by @torkelo. Anything that does not start with a P would be the default format. A "custom" entry in the dropdown would allow specifying my own format string, no matter if I need to build that outside grafana UI as its really a one-time task and PRs for additional defaults would easily be done from there on.

While a polished version would be great, after more than 4 years of waiting, me (and probably most users) would be happy to have anything at all.

So before doing anything else (like writing a design doc) I'd need to be convinced that Grafana is even remotely interested is actually engaging in the discussion and moving forward with one of the highest-ranked feature request :(

I am also frustrated. To make it clear, when demonstrating our service stacks using Grafana for visualization, I have to always excuse for our customers, who are asking about the date format, that Grafana (otherwise so great) does not know and cannot be configured to show timestamps as customers want. This is ruining all first time demonstrations as you always have to explain why such front-end and very visible feature is not working. It is basic feature and it is not working, because it is not giving what customers want. Please start taking care of this issue, please.

+1, really frustrating I can't get international date formats on the X series.

I'd be happy and supportive with an approach around a format mapping, with defaults for popular locales. We're looking for someone in the community to take on this effort though. I'm available for any guidance.

Here is an outline of the work needed:

• you can use #18659 as a starting point, thanks @andig
• specify a date mapping that has formats for various time resolutions
• potentially rewrite the monthDayFormat to store the selected mapping
• add logic to use the mapping in the graph date formatter
• add mappings for popular locales in a dropdown
• provide a custom option in the dropdown to provide own mapping
• add error handling around custom mapping
• write tests for mapping validation
• update documentation

Please reach out to me or @torkelo on our public slack if you want to take this on. Before starting any work, make sure to post here as well. See also our guidelines for contributions.

Great to see this moving!

specify a date mapping that has formats for various time resolutions

I think what we can do here is come up with a comprehensive list of date formats. However, we should first clarify the parameters.
Current code relies on both tick length and chart range for choosing formatting. Original float only uses tick length and checks if length is below fixed intervals (minute, day, month, year). If we want to keep this flexible then I would propose:

• make intervals configurable
• use ISO notation (supported by both Go and momentjs)
• check tick length against intervals, if below interval you have your format
• there should be pre-configured locales and the ability to use your own format

That would require something like a mapping table as suggested in https://github.com/grafana/grafana/pull/13429. The US might look something like this (need to double-check the moment format strings). Remember the durations would be tick size upper bound:

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

Germany would look like this:

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

UK (assumption) would look like this (12 hour format):

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

Formatting could come in config file or UI-based. For UI-based, it might make sense to have defaults for popular locales (at least US) and allow free-text user-based config. The latter could just be:

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

This discussion is a bit insane. It's showing off, in public, a disconnect between some of the core grafana developers and some of its users.

As a European user (and developer but not grafana dev), I'd certainly like this feature. I'm also aware that grafana is (to my knowledge) developed mostly by people as volunteers in their spare time, and in any case all development projects have to prioritise.

Perhaps people who would like to contribute to making this feature happen could identify themselves. It's been pointed out that the grafana devs communicate on slack, so that might be the right place to do that. And then for those people to remain cognisant that all projects have procedures and that they'll be expected to abide by whatever that means here.

And perhaps a grafana dev might identify herself or himself as a patient mentor to help those people accomplish the task of getting this feature into the master branch. I think that just happened with @davkal . (Kudos.)

@JeffAbrahamson

As a European user (and developer but not grafana dev), I'd certainly like this feature. I'm also aware that grafana is (to my knowledge) developed mostly by people as volunteers in their spare time, and in any case all development projects have to prioritise.

Exactly. I am unease with the assumption of entitlement in _some_ of the comments, forgetting that Grafana is _free_ and _open source_, as I mentioned a bit above at https://github.com/grafana/grafana/issues/1459#issuecomment-469317707.

I just want to thank once more @davkal for his attempts and for his generosity.

If my comment was one that caused offence, I sincerely apologise. I am very grateful for the work put in by all towards this project.

@andig - Your assumption on UK date format looks sound, if that is a good solution.

One alternative, if I may make so bold - and not knowing any of the internals I don' t know if this is a valid suggestion, so please discard if not: A simple box on the Style page of a graph that allows the user to paste in an overriding date format for the X scale. Perhaps using the common string expansion format used elsewhere, like in php; https://www.php.net/manual/en/function.date.php could give full free-form interpretation and fit all use cases on a per-graph basis, rather than applying one format for all. (In use, I sometimes have a wish to show the day of the week rather than a date, for example)

Something perhaps:

Override X date format [ ]

Which, if set, would expand tokens like
%D %d, %M to Mon 12, Sep

%D %G:%H to Mon 13:45

Meta: just to clarify Grafana development is led by Grafana Labs staff of circa 25 developers (including me). But if you consider the size of the software that staff size is quite low, and the software would not be that useful without all the community contributions. Our challenge for features like this one here, which are not urgent but important, we'd like to find a way to enable the community to develop the feature. We have plenty of success stories of important individual contributions, and I'd be more than happy to guide you through this process ([email protected]).

A simple box on the Style page of a graph that allows the user to paste in an overriding date format for the X scale.

I'm less of a fan since changing this all over the system will be an ongoing burden when new dashboards are added in the user's org. So far I'm still advocating for the approach laid out above.

For sake of transparency: I have taken the rebase as far as I could without a) ability to test (see pr for issues encountered) and b) in-depht frontend development knowledge. Sorry to say you'll have to count me out.

+1, we'd much prefer anything but MMDD format :)

How can I customize the datetime format in a series in a plot? Say remove time, or change date format, or add in seconds?

+1

Above fix doesn't work for me with Grafana 6.7.1 But :

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

NB I am running this in a docker container, but otherwise I do not suggest to run this without backing up the files in /usr/share/grafana/public first.

But it works for me.

To overwrite the default entrypoint in docker-compose:
entrypoint: bash -c "find /usr/share/grafana/public -type f -exec sed -i 's@%m/%d@%d/%m@g' {} + && /run.sh "

Thanks, for those who want the German version (1.4 instead of 1/4) then the following?
bash -c "find /usr/share/grafana/public -type f -exec sed -i 's@%m/%d@%d.%m@g' {} +"
Or do I need a special character in front of the dot?

apoglogies, I dont this is working, Ill get back if I find a solution,

Above fix doesn't work for me with Grafana 6.7.1 But :

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

NB I am running this in a docker container, but otherwise I do not suggest to run this without backing up the files in /usr/share/grafana/public first.

But it works for me.

To overwrite the default entrypoint in docker-compose:
entrypoint: bash -c "find /usr/share/grafana/public -type f -exec sed -i 's@%m/%d@%d/%m@g' {} + && /run.sh "

Isn't that nice. Another year has passed, Grafana is nearing version 7, localization is considered "a small thing" despite being the 4th-highest ranked feature request and here we are hacking the binaries...

Yeah, I would be interested to have a word with the product owner. Why is this feature request not higher on the list? High demand, possible, long history, increase in sales/usability... what else would a PO need?

@davkal could you kindly tag this as type/feature-request as per https://github.com/grafana/grafana/issues/1459#issuecomment-523313533 so it does at least show up in your prioritizations?

I am one of the product owners and listed my email and the public slack as ways to get in touch. Nobody has contacted me.

Our invitation to contribute is still open. The steps are laid out above. We're maturing as an engineering org, so for this endeavour the party who'd like to work on this should start a design doc. See this one for an example.

I am one of the product owners and listed my email and the public slack as ways to get in touch. Nobody has contacted me.

@davkal I don't know how to react but what you're writing makes me sad:

• I've personally tried to highlight the importance of this request https://github.com/grafana/grafana/issues/1459#issuecomment-523313533
• tried to forward specification https://github.com/grafana/grafana/issues/1459#issuecomment-528817275
• I've tried- albeit with limited skill- to take up pushing an abandoned PR further (https://github.com/grafana/grafana/pull/18659) and asked for help https://github.com/grafana/grafana/pull/18659#issuecomment-523422092
• been told that should be abandoned:

Not going forward with this, see also #13429

• been told in https://github.com/grafana/grafana/pull/13429 that:
  Not going forward with this, will retry with more comprehensive approach.

And how you're saying:

Nobody has contacted me.

I'll not say more but don't feel appreciated right now.

Your effort was certainly appreciated @andig and you tried to advance the issue. My point is, there was no other discussion apart from ours (the one above in Sep 2019).

To clarify again: localization of graph formats makes a ton of sense, and it's on the roadmap. Perhaps we can even get to it this summer, but don't rely on us for that, roadmaps can change. If this feature will bring value to you, then feel free to contribute and make it happen sooner.

Hope it will be there soon, grafana lacks some basic features like this one (format date with user settings...)

It looks like stackdriver timeRange url query params expect ISO 8601 formatted times and not unix timestamps. Having ISO formatted time for this would unlock linking to stackdriver from panels (with the current time). Thanks for all the hardwork!

Can anyone provide a SED/patch solution for Grafana 7? (m/d) -> (d/m)

Little PR to make things better. https://github.com/grafana/grafana/pull/25602.
Suggests to use local browser format for graph panel.

Looks like an option is coming soon, but for those who are looking for a quick fix:

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

Works on Grafana v7

+1, can't believe such a trivial thing has been in discussion for 5+ years
do enterprise users of Grafana suffer from the same issue as well?

Ha ha. 5 years passed. It is shame.

Please prioritize getting this fixed. Graphs with mm/dd formatting are so useless.

I do not care about the perfect solution of letting each users be able to chose an individual formatting, a single system setting for date formatting is ok as long as I am able to avoid exposure to this horrible date formatting abnormality.

System date formatting options just got merged https://github.com/grafana/grafana/pull/27216

Adds these ini settings

[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

Please test and give feedback. Plan to add org level settings for this as well in a future release. The use_browser_locale still has some kinks to fix (detect 12 vs 24 hour time). A first_day_of_week option could also be a good addition to add to this.

Thanks @torkelo much appreciated!

Here is an example

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

That is wonderful news, thank you very much! I restarted grafana but the new format did not show up. Which version should I install - can you point me to a site explaining this?

Nightly build or wait for 7.2 beta (very soon)

Nightly build or wait for 7.2 beta (very soon)

How often is the master tag at dockerhub updated? It's two days old, would it be possible to trigger it more often?

Nice one @torkelo - the following is working nicely on the grafana:7.3.5 docker image (docker-compose.yml excerpt):

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

However, setting GF_DATE_FORMATS_USE_BROWSER_LOCALE=true did not work for me here in Australia, using Firefox on a mac - the short date formats remained in the US-specific MM/DD format.