Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-6074

I can use webapps in different timezones

    Details

      Description

      Context:

      • different users in different timezones use the tasklist collaboratively

      Problem Description
      Example 1:

      • Given User 1 in Timezone 1 and User 2 in Timezone 2
      • if User 1 sets the Duedate for a task
      • then, in the default configuration, it shows up wrong in the when User 2 looks at the task
      • expected: the timezone offset is taken into account when sending duedate on backend and showing the duedate to User 2

      Example 2:

      • Given User 1 in Timezone 1 and User 2 in Timezone 2
      • if User 1 creates a task
      • then a wrong value for "created X minutes ago" is shown
      • expected: "created X minutes ago does not include a timezone offset

      Example 3:

      • Given User 1 in Timezone 1 and Process Engine in Timezone 2
      • if process engine creates a task or sets the duedate for a task
      • expected: offset between process engine timezone and user timezone is taken into account when displaying create time

      AT:

      • Using tasklist in different timezones works

      Implementation Notes:

      • Rest API inside Webapp returns all dates in UTC
      • Webapp converts dates into user's local time before displaying them
      • Webapp converts all dates to UTC before sending them to the server

      Problems:

      • backwards compatibility of Rest API
      • special considerations for dates in task forms?

        Issue Links

          Activity

          Hide
          meyer Daniel Meyer added a comment -

          The backwards compatibility problem I see is changing the format in which the rest api returns the formatted dates.
          If users access that directly (for instance in a form or a custom plugin) then it may be an issue.
          But I have not completely thought it through yet.

          Show
          meyer Daniel Meyer added a comment - The backwards compatibility problem I see is changing the format in which the rest api returns the formatted dates. If users access that directly (for instance in a form or a custom plugin) then it may be an issue. But I have not completely thought it through yet.
          Hide
          thorben.lindhauer Thorben Lindhauer added a comment -

          Ok, makes sense. Perhaps one of the frontend devs can tell if one of the two options is "nicer" with respect to that:

          "12:00:00" (before fix, time in JVM-local zone) => "15:00:00" (after fix, time in UTC)
          "12:00:00" (before fix, time in JVM-local zone) => "12:00:00 FOO" (after fix, time in JVM-local zone with identifier)

          Show
          thorben.lindhauer Thorben Lindhauer added a comment - Ok, makes sense. Perhaps one of the frontend devs can tell if one of the two options is "nicer" with respect to that: "12:00:00" (before fix, time in JVM-local zone) => "15:00:00" (after fix, time in UTC) "12:00:00" (before fix, time in JVM-local zone) => "12:00:00 FOO" (after fix, time in JVM-local zone with identifier)
          Hide
          pescador_bob Brent Fisher added a comment -

          Perhaps you could simply create a new version of the endpoint for us to use? Then folks can upgrade at their leisure. We are also experiencing pain in this area. I'd be happy to provide a PR if that would help.

          Show
          pescador_bob Brent Fisher added a comment - Perhaps you could simply create a new version of the endpoint for us to use? Then folks can upgrade at their leisure. We are also experiencing pain in this area. I'd be happy to provide a PR if that would help.

            People

            • Assignee:
              Unassigned
              Reporter:
              meyer Daniel Meyer
            • Votes:
              3 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: