Well there are two options. Either use a 100% numeric date (i.e. 01-05-2016) or implement our own DateTime object to handle formatting the same way JDate in the CMS does. Unfortunately translating anything from PHP's date functions is tricky.

Thanks to the USA I don't recommend using a pure numeric format.

And without introducing the CMS' concept of translatable date/time formats all of the day-month-year notations aren't correct for us.

Another possibility might be to dig deep into the PHP API and make use of the intl extension

Just deployed 75d39f5 which uses the PHP intl extension to format the dates, and translate them. I've gone through a large chunk of the languages and things seem to be fine with that snippet, so if that's the case we could make the same change to other date labels in the charts and call this complete.

I am, once again, surprised by the way you find simple solutions to problems that are quite complex...
I am, almost, even more surprised that we can use the intl extension on our live server environment.
Can our non *nix devs get that thing installed? @b2z?

Should become part of the language handling class ?

Shouldn't be too complex to install. Per the documentation it's just passing a flag when you compile PHP, so if you're using an *AMP stack it would be dependent on how that was built. And at least from what I've seen it's enabled on any decent hosting provider these days. And if for whatever reason you CAN'T get the intl extension, there's Symfony's intl component (sadly only supports English, but at least keeps your code from erroring out).

I did not have a problem with it - my WampServer installation has php-intl package ;)