5 Replies Latest reply on Oct 2, 2010 2:12 PM by h.peter

    Concept of different locales/time zones in jBPM5

    h.peter

      Hello All,


      I believe the work on the upcoming release of jBPM has already been started - at least the planning, requirement gathering and establishing basic concepts. What I don't really see is the way times and dates will be handled by jBPM 5.

       

      As far as I know the current 4.4 version does not really have any concept of different locales or time zones and business calendars: it seems that the assumption is that all end users / workflow actions will be in the same time zone.


      This is a limitation even small / midsized companies can hit. Although having say a few hours difference between the US east and west coast might not be a big deal in most of the cases but the lack of locale/time zone support can be significant in other cases. For example I don’t really see the means to handle the scenario where your workflow crosses country borders and you want to set the task due date expressed in business days according to the local environment.


      Or if you have an application running with jBPM embedded into it in different time zones, but using the same database you might experience strange issues: some tasks might seem to be created in the future from a different time zone; or since the audit history contains the timestamps using the local date and time you might see a task being completed before the previous step, or even the before the date the task itself was created.

       

      What do you think about this – is there any plan to include support for different locales / time zones and business calendars in jBPM 5?

        • 1. Re: Concept of different locales/time zones in jBPM5
          rebody

          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

            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

              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

                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

                  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.