Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-28096

As a v2 editor, I want to see relative dates

    Details

      Description

      The various dates displayed by the UI would be more readable if they used a relative date and time format:

      • "5 minutes ago"
      • "a few seconds ago"
      • "yesterday"
      • "last year"
      • "two years ago"

      The real date must still be available when hovering on a date.

      Benefits

      We agreed in a discussion that relative dates are more practical in most cases, as long as the exact date is easy to get in addition (tooltip). It also helps leverage the topic of server vs client time, as a relative date will be valid independently of the timezone (reminder: dates are stored using the server's time).

      Technical requirements

      Back/Frontend

      This should happen in every UI element, both server side and frontend generated elements. Without much data about this option, it sounds more logical to do this on the server side.

      3rd party libraries or not ?

      See open questions below. There are apparently libraries for this, even though their freshness should be verified first.
      Examples/candidates:

      PHP API

      The code used to handle this should be re-usable, and maybe part of a Site API (e.g. public and maintained).
      Twig support should be included.

      REST API

      The option of exposing this through the REST API as well should be considered. It would be fairly easy since we can add new elements, for instance by means of REST Field Type Processors.

      Documentation
      • Developer doc: this should be documented for those extending the UI, be it with FieldTypes or custom UIs.
      • User doc: the screenshots that feature the date should be updated.

      Open questions

      To dev team

      • Clarify if we would use a 3rd party library or custom code (both are fine, as it really depends on the available libraries and on what formats they support (see below).
      • What exact formats do we want to support ? If we use a 3rd party library, we should stay close from what it supports. In any case, we need the exact answer to this question to complete the requirements. This may involve that dev has a look at the options, and define if it would be custom code or a 3rd party library.

      To UI team

      Should this be applied everywhere ? Or only to some/most dates ?

        Activity

        Hide
        Sylvain Guittard added a comment -

        For 3rd party library we also have https://momentjs.com/ and there is also https://momentjs.com/timezone/ for timezones.

        Show
        Sylvain Guittard added a comment - For 3rd party library we also have https://momentjs.com/ and there is also https://momentjs.com/timezone/ for timezones.
        Hide
        Bertrand Dunogier added a comment - - edited

        About the momentjs proposal, we need to consider the consequences of using a client side library for this:

        • relative dates are not made available over REST, nor using a PHP API. They can only be displayed in a browser (think notifications, emails, etc)
        • about timezones, an advantage of using server side generated relative dates was that we didn't have to care: dates are stored with the server's time, and relative dates are computed based on the same server's time. No risk of errors. By moving it to the client's side, we need to make sure we take into consideration the client's timezone, or else the relative dates will be wrong.

        I'm not sure I'm comfortable with this, given that one of the objectives was to avoid fiddling with client vs server time.

        I have nonetheless added the suggestion to the description, as well as Knp's TimeBundle that has support for it as well.

        Show
        Bertrand Dunogier added a comment - - edited About the momentjs proposal, we need to consider the consequences of using a client side library for this: relative dates are not made available over REST, nor using a PHP API. They can only be displayed in a browser (think notifications, emails, etc) about timezones, an advantage of using server side generated relative dates was that we didn't have to care: dates are stored with the server's time, and relative dates are computed based on the same server's time. No risk of errors. By moving it to the client's side, we need to make sure we take into consideration the client's timezone, or else the relative dates will be wrong. I'm not sure I'm comfortable with this, given that one of the objectives was to avoid fiddling with client vs server time. I have nonetheless added the suggestion to the description, as well as Knp's TimeBundle that has support for it as well.
        Hide
        Sylvain Guittard added a comment -

        About timezones:
        I don't know if it helps but I think it makes sense to let the user decide which timezone he / she wants to use. I can definitely see this option associated with the user account (preferences). So maybe the server side option is better.
        I also think that we should inform the user when the computer time is in a different timezone than the one he / she selected (user preferences).

        Show
        Sylvain Guittard added a comment - About timezones: I don't know if it helps but I think it makes sense to let the user decide which timezone he / she wants to use. I can definitely see this option associated with the user account (preferences). So maybe the server side option is better. I also think that we should inform the user when the computer time is in a different timezone than the one he / she selected (user preferences).
        Hide
        Bertrand Dunogier added a comment -

        Of course. We have discussed that several times.

        But remember that the goal of this story was to get clean dates and avoid the server/client timezone question completely. Adding this option changes it from small & useful to big & useful. I'd rather for the earlier

        Show
        Bertrand Dunogier added a comment - Of course. We have discussed that several times. But remember that the goal of this story was to get clean dates and avoid the server/client timezone question completely. Adding this option changes it from small & useful to big & useful. I'd rather for the earlier
        Hide
        Bertrand Dunogier added a comment -

        Ping Sylvain Guittard I really liked this one, and it might still be a very worthy improvement.

        Show
        Bertrand Dunogier added a comment - Ping Sylvain Guittard I really liked this one, and it might still be a very worthy improvement.
        Hide
        Sylvain Guittard added a comment -

        Good to see that this topic is back
        Feel free to ping the dev team.
        Inaki Juaniz-Velilla and Supriya Bhargava we will have to review all the screens and decide where this new feature should apply

        Show
        Sylvain Guittard added a comment - Good to see that this topic is back Feel free to ping the dev team. Inaki Juaniz-Velilla and Supriya Bhargava we will have to review all the screens and decide where this new feature should apply

          People

          • Assignee:
            Bertrand Dunogier
            Reporter:
            Bertrand Dunogier
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: