-
1. Re: Concept of different locales/time zones in jBPM5
rebody Sep 17, 2010 8:36 AM (in response to h.peter)Hi Peter,
I think it is a very important feature for the BPM engine, Do you have any advice for jBPM 4? Thank you very much.
-
2. Re: Concept of different locales/time zones in jBPM5
mwohlf Sep 18, 2010 4:29 AM (in response to h.peter)Hi Peter & HuiSheng,
I don't think the workflow engine should deal with things like timezones, DST or any kind of internationalization, that's not the job of the workflow engine. All dates and times the engine is dealing with should be UTC. Internationalization and localization, including calculating the local time for a specific user should happen in the user interface layer not in the core workflow engine.
The business calendar is a different story, right now there is a single business calendar per engine instance, and this doesn't cover all usecases. There might be users in different countries with different holidays. Having a business calendar per user seems to be a better approach but also a lot of overhead since most calendars are probably the same, but to me this seems to be the only change that is neccessary in jBPM4 to do localization.
Of course I might miss something, so please let me know if you think this wouldn't work...
-
3. Re: Concept of different locales/time zones in jBPM5
h.peter Sep 25, 2010 3:15 PM (in response to mwohlf)Hello,
I absolutely agree that internationalization should be the responsibility of the presentation layer. The problem is that the current implementation of jBPM neither store nor use UTC time and date internally: the engine always rely on the local time and date which can lead issues in an environment where your clients are in different locations (and time zones).
Modifying the current version is a bit tricky - that's why I think this issue should be considered from the beginning of jBPM 5's development. Basically, in jBPM 4 the current date is estabilished by org.jbpm.pvm.internal.util.Clock.getCurrentTime() method. The current implementation simply returns 'new Date()' which contains the local timestamp. If the UTC time was returned here that would mean that you store the date consistently from all locations but at the same time, you would also have to modify the code in a lot of places (date based queries in service interfaces; JobExecutor service scheduling etc) so I am a bit reluctant to say that all these parts should be rewritten.
I understand that providing support for different time zones and business calendars might seem to be a huge overhead without too much gain but I think that providing at least some extenstion points to allow you to hook in your own solutions is essential. I am not sure what others think about this but my feeling is that the lack of time zone / different business calendar support is the last major argument one could raise agains using jBPM in a large scale enterprise environment. Apart from this issue I do think that from many perspectives it is better than a number of other commpercial workflow engines.
-
4. Re: Concept of different locales/time zones in jBPM5
mwohlf Sep 26, 2010 5:01 AM (in response to h.peter)Hi Peter,
I agree with you that timezones should be considered from the beginning of jBPM5's development.
But I don't see your point about jBPM4, what i don't understand is this:
[...]
The problem is that the current implementation of jBPM neither store nor use UTC time and date internally: the engine always rely on the local time and date which can lead issues in an environment where your clients are in different locations (and time zones)
[...]
The current implementation simply returns 'new Date()' which contains the local timestamp. If the UTC time was returned here that would mean that you store the date consistently from all locations but at the same time, you would also have to modify the code in a lot of places (date based queries in service interfaces; JobExecutor service scheduling etc) so I am a bit reluctant to say that all these parts should be rewritten.
Why do you think the engine uses local time internally?
This is from JavaDoc for java.util.Date:
Although the
Date
class is intended to reflect coordinated universal time (UTC), it may not do so exactly, depending on the host environment of the Java Virtual Machine. Nearly all modern operating systems assume that 1 day = 24 × 60 × 60 = 86400 seconds in all cases. In UTC, however, about once every year or two there is an extra second, called a "leap second." The leap second is always added as the last second of the day, and always on December 31 or June 30. For example, the last minute of the year 1995 was 61 seconds long, thanks to an added leap second. Most computer clocks are not accurate enough to be able to reflect the leap-second distinction.So my understanding so far was that jBPM4 uses UTC already internally (which may be off by some seconds on some platforms), but as far as I understand you don't agree on that?
-
5. Re: Concept of different locales/time zones in jBPM5
h.peter Oct 2, 2010 2:12 PM (in response to mwohlf)Hi Michael,
That's a good point, according to the documentation java.util.Date should indeed contain an UTC date. I did see some weird task timestamp issues in our jBPM tables I did not understand - I'll investigate that a bit further.