Hi Deepak,
A few years ago we modified the JobSandbox table to include a temporal
expression timezone field, that allowed a UTC based OFBiz to schedule
recurring jobs according to a specific timezone but ultimately store the
next runTime back in UTC. I had thought that improvement had made it back
into OFBiz, but I can't see it so I guess it didn't.
Regards
Scott
On Mon, 6 Nov 2023 at 04:52, Deepak Dixit <dee...@apache.org> wrote:
> Thanks Scott for the review and input.
>
> I agree we can use UTC, but in this case we need to reschedule the job
> timings according to the user timezone.
> eg.
> - Reporting jobs that runs on specific time
> - Some business process, like order routing job etc. that should run on
> specific time,
>
> Please correct me if I am missing something?
>
>
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org
>
>
> On Fri, Nov 3, 2023 at 2:38 PM Scott Gray <scott.g...@hotwaxsystems.com>
> wrote:
>
> > Hi Deepak,
> >
> > IMO the best general solution is to not run OFBiz or the database
> > configured with a timezone that observes DST, instead use UTC or similar.
> > This achieves the same result but without needing any extra fields.
> >
> > I'm not objecting to your solution, just sharing this tip out loud since
> > the JobSandbox is only one of many places that can have trouble with
> > ambiguous DST date/times and it is very difficult to change timezone at
> the
> > db level once it's filled with production data.
> >
> > Regards
> > Scott
> >
> > On Mon, 30 Oct 2023 at 13:05, Deepak Dixit <dee...@apache.org> wrote:
> >
> > > The issue occurs when DST changes, and OFBiz fails to schedule
> recurring
> > > jobs properly.
> > > This is due to a condition in the PersistedServiceJob.createRecurrence
> > > method where it compares the next scheduled time (next) with the start
> > time
> > > (startTime) for the job.
> > >
> > >
> > > *Proposed Solution:*To address the issue, adding a new field named
> > > JobSandbox.runTimeEpoch. This field would store the UTC epoch
> > milliseconds
> > > of the runtime date.
> > > When scheduling or rescheduling recurring jobs, the system would use
> the
> > > UTC epoch stored in JobSandbox.runTimeEpoch for recurring job
> comparison.
> > >
> > > This solution ensures that the system uses a consistent, UTC-based time
> > for
> > > scheduling and rescheduling recurring jobs, even when DST changes
> affect
> > > the local time.
> > >
> > > To implement this solution, we need to do following things:
> > >
> > > - Modify the PersistedServiceJob.createRecurrence method to calculate
> and
> > > store the UTC epoch milliseconds in the JobSandbox.runTimeEpoch field.
> > > - Update the code responsible for polling and rescheduling jobs to use
> > the
> > > JobSandbox.runTimeEpoch field when it is set. If the field is not set,
> It
> > > would fall back to getting the runtime date to filter the jobs.
> > >
> > > By using this approach, the system should be able to handle recurring
> job
> > > scheduling more reliably, especially when DST changes are involved, as
> it
> > > ensures that all time comparisons are made in a consistent UTC format.
> > >
> > >
> > > Thanks & Regards
> > > --
> > > Deepak Dixit
> > > ofbiz.apache.org
> > >
> > >
> > > On Tue, Oct 17, 2023 at 11:00 AM Deepak Dixit <dee...@apache.org>
> wrote:
> > >
> > > > Hi Dev,
> > > >
> > > > I wanted to draw your attention to an issue we've encountered with
> the
> > > > OFBiz job scheduler, particularly when it comes to handling Daylight
> > > Saving
> > > > Time (DST) changes.
> > > >
> > > > It appears that the job scheduler fails to create new recurring jobs
> > when
> > > > DST ends, especially when the tempExprTypeId is set to FREQUENCY
> (e.g.,
> > > 15
> > > > minutes, 30 minutes).
> > > >
> > > > Upon further investigation, we've identified that the following
> > condition
> > > > in PersistedServiceJob.createRecurrence might be the root of the
> issue:
> > > >
> > > > java
> > > >
> > > > if (next > startTime) {
> > > > // ...
> > > > // ...
> > > > }
> > > >
> > > > I'm curious to know if anyone else has encountered a similar problem
> or
> > > if
> > > > you have any insights to share regarding this issue.
> > > >
> > > > Thanks & Regards
> > > >
> > > > --
> > > > Deepak Dixit
> > > > ofbiz.apache.org
> > > >
> > >
> >
>
