Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Medium Medium
    • Resolution: Obsolete
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      All ezdatetime fields are empty in content editing form. This happens due to incorrect date format used by default in Symfony's DateTimeType. It applies timezone information which is unsupported by <input type="datetime-local" />.

        Issue Links

          Activity

          Hide
          Maciej Kobus added a comment - - edited

          Bertrand Dunogier [~damien.pobel@ez.no] I tried stripping timezone information assuming server timezone will be used but after discussion with [~yannick.roger@ez.no] we agreed this isn't a solution at all.

          What we can do:

          • provide another input with timezone offset (the easiest but not so convenient for editors)
          • timezone setting as a part of user content type
          • replace <input type="datetime-local" /> with text input (using timestamp as a value) and use JS date picker instead
          Show
          Maciej Kobus added a comment - - edited Bertrand Dunogier [~damien.pobel@ez.no] I tried stripping timezone information assuming server timezone will be used but after discussion with [~yannick.roger@ez.no] we agreed this isn't a solution at all. What we can do: provide another input with timezone offset (the easiest but not so convenient for editors) timezone setting as a part of user content type replace <input type="datetime-local" /> with text input (using timestamp as a value) and use JS date picker instead
          Hide
          Gunnstein Lye added a comment - - edited

          > timezone setting as a part of user content type

          Users will travel and forget to update the setting. Could be used to provide a default value for a timezone input, though.

          Better might be to use geolocation to provide a default value for a timezone input, but then we depend on such a service. And cross-timezone VPNs may confuse it, so users will have to verify the value. I think that no matter how this is implemented, there must be a way for the user to set the timezone manually.

          Don't we need the same thing for the Time type? And even Date, since internally it uses a timestamp AFAIR, which could lead to date errors if the timezone is wrong (in edge cases).

          Show
          Gunnstein Lye added a comment - - edited > timezone setting as a part of user content type Users will travel and forget to update the setting. Could be used to provide a default value for a timezone input, though. Better might be to use geolocation to provide a default value for a timezone input, but then we depend on such a service. And cross-timezone VPNs may confuse it, so users will have to verify the value. I think that no matter how this is implemented, there must be a way for the user to set the timezone manually. Don't we need the same thing for the Time type? And even Date, since internally it uses a timestamp AFAIR, which could lead to date errors if the timezone is wrong (in edge cases).
          Hide
          Damien Pobel (Inactive) added a comment -

          The timezone strikes back Indeed in PlatformUI v1 we had a dirty hack (see EZP-24040 and corresponding fix) to somehow autocorrect the date and time value. Basically, we consider that what we store in the database is a timestamp representing the UTC value of a date and time. When displaying the form, the date and time value was adjusted according to the user timezone and when submitting the edit form, the value was adjusted again in UTC to be stored correctly by the server. This was doable because the app was completely in JS.
          Now that we are back in a server driven mode, this is a bit more complicated to achieve because the server can not get the user timezone in a reliable way to apply the trick and we have to remember that we also want the content edit form to work in a minimal way without all the stuff in the admin.

          But as a simple way to move forward on that topic, I think we should implement that in the following way:

          1. contrary to what I wrote in https://github.com/ezsystems/hybrid-platform-ui/blob/master/docs/specs/field_edit_markup.md, we should use 2 inputs in the form a date input and a time.
          2. when displaying the form, those inputs should be filled with either the UTC values or values in the timezone configured in PHP
          3. when submitting the form, those inputs should be interpreted either as UTC values or values in the timezone configured in PHP (as long as it's consistent, than fine for now)

          at least, we'll have a consistent behavior on which we can improve (even if this can be a bit confusing if users of an eZ Platform website are spread across several timezones).

          Then, as asked several times before (for instance here https://github.com/ezsystems/PlatformUIBundle/pull/842), then the PM (ping Sylvain Guittard Supriya Bhargava Inaki Juaniz-Velilla) should define once and for all how the whole date and time (and time) is supposed to behave in the application.

          Show
          Damien Pobel (Inactive) added a comment - The timezone strikes back Indeed in PlatformUI v1 we had a dirty hack (see EZP-24040 and corresponding fix ) to somehow autocorrect the date and time value. Basically, we consider that what we store in the database is a timestamp representing the UTC value of a date and time. When displaying the form, the date and time value was adjusted according to the user timezone and when submitting the edit form, the value was adjusted again in UTC to be stored correctly by the server. This was doable because the app was completely in JS. Now that we are back in a server driven mode, this is a bit more complicated to achieve because the server can not get the user timezone in a reliable way to apply the trick and we have to remember that we also want the content edit form to work in a minimal way without all the stuff in the admin. But as a simple way to move forward on that topic, I think we should implement that in the following way: contrary to what I wrote in https://github.com/ezsystems/hybrid-platform-ui/blob/master/docs/specs/field_edit_markup.md , we should use 2 inputs in the form a date input and a time . when displaying the form, those inputs should be filled with either the UTC values or values in the timezone configured in PHP when submitting the form, those inputs should be interpreted either as UTC values or values in the timezone configured in PHP (as long as it's consistent, than fine for now) at least, we'll have a consistent behavior on which we can improve (even if this can be a bit confusing if users of an eZ Platform website are spread across several timezones). Then, as asked several times before (for instance here https://github.com/ezsystems/PlatformUIBundle/pull/842 ), then the PM (ping Sylvain Guittard Supriya Bhargava Inaki Juaniz-Velilla ) should define once and for all how the whole date and time (and time) is supposed to behave in the application.
          Hide
          Gunnstein Lye added a comment -

          Confirmed, Date uses a timestamp too, so all 3 date and/or time types are affected by timezone issues, and should be dealt with in similar ways. Example for Date, if server and user are in different timezones, and the user, close to midnight, creates content with a Date which has default value of todays date, then the "current date" shown may be 1 day earlier or later than the user expects it to be.

          Re: DST, if we are going to show timezone when editing/viewing date and/or time, we may need to show DST status too.
          Egad. https://xkcd.com/1883/

          Show
          Gunnstein Lye added a comment - Confirmed, Date uses a timestamp too, so all 3 date and/or time types are affected by timezone issues, and should be dealt with in similar ways. Example for Date, if server and user are in different timezones, and the user, close to midnight, creates content with a Date which has default value of todays date, then the "current date" shown may be 1 day earlier or later than the user expects it to be. Re: DST, if we are going to show timezone when editing/viewing date and/or time, we may need to show DST status too. Egad. https://xkcd.com/1883/
          Hide
          Maciej Kobus added a comment -

          Closing as this is related to Hybrid UI, we changed the approach in Admin UI.

          Show
          Maciej Kobus added a comment - Closing as this is related to Hybrid UI, we changed the approach in Admin UI.

            People

            • Assignee:
              Unassigned
              Reporter:
              Maciej Kobus
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: