Hello,
I am intending to create a process that starts at 6 PM in the timezone of the user, not the time zone of the server. I tried to use the variable replacing feature shown in the documentation, so instead of defining the timer with T18:00, I put T18:00${timeOffset}. And I will set the time offset variable at the instantiation of the process with ${timeOffset} value set to “-03:00”.
If I create a DURATION timer in the process and set the T18:00${timeOffset}, I get an exception showing me that the T18:00-03:00 cannot be parsed. This is a correct exception as I defined the timer of the type DURATION. Also, the exception shows that the variable was replaced with the correct value.
Now if I change the type of the timer to “DATE” the exception does not happen, but the timer does not work (immediately move to the next task) and when I look at the definition of the timer in Cockpit I see that the variable was not replaced I see: T18:00${timeOffset}. That is wrong as the variable should be replaced.
I also replaced the expression to have only ${time} and set the time to T15:00, before instantiating the process, but because the variable is not replaced when the timer is of type DATE, the timer does not work…
Is this a bug or there is something I do not understand how these timers and time format work?
Thank you
Hi @eflorez,
Have you tried creating an expression like ${time.concat(offset)}, where time is the time String variable and offset is the desired offset variable?
Regarding how timers work, when you define a time when a Timer should execute, this is actually translated into a Job instance, and the execution time is the Job’s DueDate. In the database, the Job#DueDate column is represented as a timestamp [without timezone], meaning that the database persistent date won’t contain any timezone information. For example, if your server and db server timezones are +01:00, and you pass a Date with timezone +03:00, the Date will first be converted to the server timezone (+01:00) and then it will be persisted in the database. You can read more about timezones in Camunda here: https://docs.camunda.org/manual/latest/user-guide/process-engine/time-zones/
Best,
Nikola
2 Likes
Hello NiKola,
Thank you for your quick response. The solution you are suggesting will not work in my case ( ${time.concat(offset)} ) as it is not the process instantiation the one that defines the time the process should start, but the process definition. Then the BA will set the time (while defining the process) to 6:00 PM and when the process gets instantiated, then we have to modify that time to the correct timezone (as we will know the users time zone only just before the instantiation is needed). That is why I was trying to have in the definition of the timer something like T18:00${timeOffSet}. …
Something that I also tested is if I set the DATE timer in the definition as T18:00 (With not offset) … the timer does not generate exception, but it starts immediately with not delay. But… it should not start until 6 PM… I also tested giving this time in the format: 18:00 (without the T)… and still does not work. But if I put 2019-10-07T18:00 then the timer works… SO apparently the DATE timer does not accept time definitions only but the combination date/time, and that is limiting in my case.
Any other way I can have the definition to indicate 6:00 PM and the instantiation to shift it to a particular time zone?..
Thank you again.
Elkin