Regression issue: date format problem on axis metrics of Time based charts

Help me!
1

Hi,

I recently noticed that you changed the format in which the axis metrics are displayed.

I have many different dashboards, and I used to write my own SQL requests because it is much faster for me.

My typical requests for selecting the time series are the following ones:

SELECT
    to_char(DATE_TRUNC('day', created_at
          at time zone 'Europe/Paris'), 'DD Mon YYYY') AS key,
    SUM(.......)                       AS value
FROM xxxxxxxxxxxxx
WHERE
        yyyyyyy
GROUP BY
        DATE_TRUNC('day', created_at
                   at time zone 'Europe/Paris')
ORDER BY
        DATE_TRUNC('day', created_at
                   at time zone 'Europe/Paris')
;

As you can see, the type of the key is a String, and this way of doing was letting me display the time series exactly as I want.

Now, it is no more the case: it seems that you try to consider this serie as a time value, and you are applying a date format on the serie.

The new display looks like this:
image

It does not display as I would like it to be displayed.
It is displayed in an environment dependent locale: ‘MM/DD/YYYY’
instead of the one that I coded: ‘DD Mon YYYY’

This is a regression, as it was working well before.

Could you please help me to make it work as expected?

Thanks in advance

My local setup:

    "database_type": "postgres",
    "liana": "forest-express-sequelize",
    "liana_version": "6.6.3",
    "engine": "nodejs",
    "engine_version": "12.13.1",
    "orm_version": "5.22.3"
2

Hello @Louis-Marie,

Sorry to hear about this.

I can reproduce your issue and shared it with the team. There is indeed a format override on our side.

The work around I can share for now is to reduce the length of your date format. Using DD Mon YY should work.
But I understand that it is not ideal, especially if you have many charts.

3

Hi team,

Any news please? I have tons of charts in many different environments.
It would take hours to make all the changes everywhere.
Is it possible to rollback your changes or apply a fix to test the datatype before applying your own format?

The longer you wait, the more users you will have affected by this change in one way or the other.

Thanks in advance

4

Hi @Louis-Marie,

Sorry to hear about this bad behaviour. We were thinking that was the case since “day one”.

In order to fix the problem as soon as possible can you give more informations ? Since when do you encounter those problems ?

Thanks in advance. It would be very helpful for our team.

Truly yours,
Morgan PERRE

5

Hi @morganperre

In order to fix the problem as soon as possible can you give more informations ? Since when do you encounter those problems ?

Unfortunately, it is very difficult for me to say it, but I would say that it came at the same time we began to have a modified display format of all our dates. The dates are now displayed depending on the locale format, so I guess that the display issue on the dashboards may be linked to the same origin.
I cannot say more than this hypothesis.

However, once again, since my dates are transformed to Strings before being displayed, the date format should not be applied to them.

Thanks in advance

6

Hi again,

It’s weird because our code base for this specific feature haven’t change with the internationalised dates.

However, once again, since my dates are transformed to Strings before being displayed, the date format should not be applied to them.

I totally agree, but today we still support some very old agent version and at the time they were returning string value…

We are gonna make some internal tests to see if we can still support old version and your use case. I’ll be back as soon as possible with a clear answer.

Thanks for your patience.