Uploaded image for project: 'OpenIDM'
  1. OpenIDM
  2. OPENIDM-11879

Workflow time zone handling is not consistent and leads to unexpected results


    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s:
    • Fix Version/s: 7.0.0
    • Component/s: Module - Workflow
    • Environment:
      Postgres 9.3.24
    • Target Version/s:
    • Verified Version/s:
    • Story Points:
    • Sprint:
      OpenIDM Sprint 7.0-5
    • Support Ticket IDs:


      Problem description

      When a workflow processinstance / taskinstance is created, the time written to the database is not UTC but the timezone of the server.  The endpoints (e.g. /openidm/workflow/processinstance?_queryId=filtered-query) returns the same time value but interpret the time as UTC.

      For example:

      1. Create a workflow at 2018-10-12 2PM local time in Germany (UTC+2)
      2. Time is written to the database as '2018-10-12 14:00:00.000' (so in local time)
      3. When requesting the processinstance the time is incorrectly interpreted as UTC: 2018-10-12T14:00:00.000+*Z+*
      4. IDM then converts the time back to the German timezone as 2018-10-12 4PM which causes confusion to the end-users as the completion time of a finished task is shown as 2 hours in the future.


      To reproduce

      1. Use the sample workflow https://backstage.forgerock.com/docs/idm/6/integrators-guide/#testing-workflow-integration
      2. Create a processinstance and then retrieve it:
      curl  --header "X-OpenIDM-Username: openidm-admin"  --header "X-OpenIDM-Password: openidm-admin"  --request GET  "http://localhost:8080/openidm/workflow/processinstance/101"

      Note that this returns the time in UTC, for example with endTime:

      "_id": "101",
       "businessKey": null,
       "deleteReason": null,
       "durationInMillis": 230,
       "endActivityId": "end",
       "endTime": "2018-10-12T12:30:38.306Z",
       "processDefinitionId": "osgiProcess:1:4",
       "processInstanceId": "101",

      Checking the Activiti tables in the DB (MySQL in this test case):

      2018-10-12 12:30:38.306

      ...this is the server system time.





            • Assignee:
              travis.haagen Travis Haagen
              andy.itter Andy Itter
              QA Assignee:
              Alexander Dracka
            • Votes:
              1 Vote for this issue
              6 Start watching this issue


              • Created: