Hi Eric,

Thank for report this. I will check it.

Hi Eric,

I can't seem to replicate the issue. Please help me by answering the question below:

1. Is it every process instances have the same issues? Can you try to start a few more to check?
2. Do you change TimeZone after the process started? Please note that the value of Date Hash Variable won't change based on TimeZone once it is saved.
3. What is the TimeZone set in your user profile? Leave it empty to follow the TimeZone in General Settings.
4. Do you have any idea how to replicate the issue?

Thanks.

Hi Owen,

I think the time zone is not the issue (the same behavior occurs with different time zones). I always tested these with new processes. Every instance has the same issue.
You should be able to replicate the issue by:

In the Joget Settings:

1. Set the System Locale to en_Us or en_NZ
2. Un-select (if it is selected) the "use system locale to format date" checkbox
3. Optional: Set the system date format to something like dd-MM-yyyy HH:mm:ss (I think this is optional since changing the system date format doesn't seem to influence the date hash variable)
   

In a bean shell tool update two workflow variables as follows:

• var 1:  #date.yyyy-MM-dd'T'HH:mm:ss#
• var 2:  #date.yyyy-MM-dd'T'hh:mm:ss#

Then once your local time is past 12am (f.e. 14:00 / 2pm) complete the bean shell tool with the fields above.

Expected results:

• var 1: 2016-06-01T14:12:34
• var 2: 2016-06-01T02:12:34
  

Actual results:

• var 1: 2016-06-01T02:12:34 <-- wrong date format
  
• var 2: 2016-06-01T02:12:34

Then change the System Locale to de_de and you should get the expected results (even though the System Locale should not influence how the simpleDateFormat returns the time).

Thanks for your details. It is weird that few of our team members tested with the same steps but not able to replicate it. I will update you again if we got more progress. Please let me know if you have more information to replicate it.

That is quite strange. Did you try it on cloud.joget.com? I cannot replicate it on my local test environment but it does occur on the cloud instance.

I think it's contained to the bean shell... I am using this code: import org.joget.workflow.model.service.*; WorkflowManager wm = (WorkflowManager) pluginManager.getBean("workflowManager"); wm.activityVariable(workflowAssignment.getActivityId(),"created_since", "#date.yyyy-MM-dd'T'HH'%3A'mm'%3A'ss'%2B12%3A00'#"); It is now 21:00 and the code returns: 2016-06-01T09%3A00%3A00%2B12%3A00 ...

just to confirm: the date hash variable in the bean shell always returns the wrong value on the cloud.joget.com instance while the same app on my local instance returns the right value.

The same date hash variable being used in a form seems to work correctly on both environments.

Owen Ong, I now also tried using the Form Update tool (using a form variable rather than a workflow variable) with the date hash and still get the wrong time.

I have the suspicion that cloud.joget.com runs on UTC, correct?
Could it be that in cases where the system updates the time as part of an automatic workflow action it will use the local system time rather than the defined timezone in the Joget settings page?
Whenever the variable is resolved in a user-submitted form it returns the right time (in both environments).

I think this is quite an important issue to fix given that deadlines will often be based on a date/time that is set as part of an automatic action - or directly in a JSON API URL.

Thanks for looking into this guys!

thank for update. I will check again.

Hi Eric,

Thanks for your details update. I am able to replicate this issue in deadline. We will fixing it.

Best regards.

Sounds good - I will keep an eye on the changelog then. Sorry it took a while to narrow down the cases in which the issue occurs...

Hi Eric,

Thanks for your details update. I am able to replicate the issue when using deadline. It is still ok in normal tool. We will working for a fix for this.

Hi Owen Ong,

Sounds good. I am actually not using it in the deadline - but in the JSON tool. I attached a screenshot for you so that you can follow the scenario if that helps.

Hi Eric,

Can you help us by providing a simple sample app which are able to replicate your issue when using date hash variable in normal tool? I can't seem to replicate it other than using it in deadline. Thanks.

Hi Owen,

No worries - I attached a stripped down version.
You can ignore the unused variables and stuff - the only thing you need to watch regarding this issue would be the lifecycle of variable.created_since.

Just try with a 30 sec interval and look at the created_since variable in the process monitor after a few iterations. It behaves as expected on my local dev instance but it parses the wrong time on cloud.joget.com.

APP_DateHash-1-20160603224911.jwa