JobSandbox temporal expression timezone

[Scott Gray-3]

Hi all,

Trying to decide on the best way to define a temporal expression for a
recurring job where the temporal expression should be evaluated using a
timezone other than whatever the default timezone is for the system.

Use case is having a system that runs on UTC time, but needs to send a
report at 5pm Pacific Time everyday regardless of whether or not daylight
savings is in effect.

I see two options:
1. Add a field to JobSandbox such as tempExprTzId (or better name!)
2. Use whatever timezone is available in the RunTime data service context

#2 seems simplest but I'm not sure if there's scenarios where the service
should be run with one timezone while the recurrence should be scheduled
based on another?  I can't think of any.

Regards
Scott

[Rishi Solanki]

Hello Scott,
Can we think of using JobSandbox.runAsUser='myuser' and UserPreference.

<UserPreference userLoginId="myuser"
userPrefGroupTypeId="GLOBAL_PREFERENCES" userPrefTypeId="defaultTimeZoneId"
userPrefValue="UTC"/>

Also it should be fine to use RunTime data, as of now I could not see no
issues with that. The only thing is not possible is if system requires to
run a service always on specific time zone values and runtime could have
different values. So having value in database makes sense to me, and okay
with #1 of having it on JobSandbox level.

I proposed UserPreference so that no field added with possible solution and
we can achieve it. Could not think of any side effect as of now if we use
it only for schedule, in case the same can be use for different purpose
while log in, then it may have several side effects.

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems <http://www.hotwaxsystems.com/>
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
Direct: [phone]


On Tue, Mar 19, 2019 at 10:56 AM Scott Gray <[hidden email]>
wrote:

> Hi all,
>
> Trying to decide on the best way to define a temporal expression for a
> recurring job where the temporal expression should be evaluated using a
> timezone other than whatever the default timezone is for the system.
>
> Use case is having a system that runs on UTC time, but needs to send a
> report at 5pm Pacific Time everyday regardless of whether or not daylight
> savings is in effect.
>
> I see two options:
> 1. Add a field to JobSandbox such as tempExprTzId (or better name!)
> 2. Use whatever timezone is available in the RunTime data service context
>
> #2 seems simplest but I'm not sure if there's scenarios where the service
> should be run with one timezone while the recurrence should be scheduled
> based on another?  I can't think of any.
>
> Regards
> Scott
>

[Scott Gray-3]

Hi Rishi,

Thanks for taking a look!

My only concern with using runAsUser would be that recurring services
typically use the "system" UserLogin and using this approach might require
multiple UserLogin/UserPreference records if there are different recurring
services using different timezones.

Also it should be fine to use RunTime data, as of now I could not see no
> issues with that. The only thing is not possible is if system requires to
> run a service always on specific time zone values and runtime could have
> different values.
>

Yeah I think I don't like the RuntimeData idea after thinking about it, an
opposite use case to my one might cause problems, e.g.:
I want a report to run at midnight UTC every night but I want the
timestamps converted to Pacific Time because that's where my users are so I
would like to use timeZone "America/Los_Angeles" or similar for the service
context.

So I think unless other ideas come along, my preference would be for adding
a new field to JobSandbox.  I'll create a ticket within the next few days
and try to come up with a better field name.  Maybe "recurrenceTimeZone",
seems clear and somewhat concise.

Thanks
Scott

On Tue, 19 Mar 2019 at 22:24, Rishi Solanki <[hidden email]> wrote:

> Hello Scott,
> Can we think of using JobSandbox.runAsUser='myuser' and UserPreference.
>
> <UserPreference userLoginId="myuser"
> userPrefGroupTypeId="GLOBAL_PREFERENCES" userPrefTypeId="defaultTimeZoneId"
> userPrefValue="UTC"/>
>
> Also it should be fine to use RunTime data, as of now I could not see no
> issues with that. The only thing is not possible is if system requires to
> run a service always on specific time zone values and runtime could have
> different values. So having value in database makes sense to me, and okay
> with #1 of having it on JobSandbox level.
>
> I proposed UserPreference so that no field added with possible solution and
> we can achieve it. Could not think of any side effect as of now if we use
> it only for schedule, in case the same can be use for different purpose
> while log in, then it may have several side effects.
>
> Best Regards,
> --
> *Rishi Solanki* | Sr Manager, Enterprise Software Development
> HotWax Systems <http://www.hotwaxsystems.com/>
> Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> Indore,
> M.P 452010
> Linkedin: *Rishi Solanki*
> <https://www.linkedin.com/in/rishi-solanki-62271b7/>
> Direct: [phone]
>
>
> On Tue, Mar 19, 2019 at 10:56 AM Scott Gray <[hidden email]>
> wrote:
>
> > Hi all,
> >
> > Trying to decide on the best way to define a temporal expression for a
> > recurring job where the temporal expression should be evaluated using a
> > timezone other than whatever the default timezone is for the system.
> >
> > Use case is having a system that runs on UTC time, but needs to send a
> > report at 5pm Pacific Time everyday regardless of whether or not daylight
> > savings is in effect.
> >
> > I see two options:
> > 1. Add a field to JobSandbox such as tempExprTzId (or better name!)
> > 2. Use whatever timezone is available in the RunTime data service context
> >
> > #2 seems simplest but I'm not sure if there's scenarios where the service
> > should be run with one timezone while the recurrence should be scheduled
> > based on another?  I can't think of any.
> >
> > Regards
> > Scott
> >
>

[Pawan Verma]

Hello Devs,

I have logged Jira for this improvement. Here is the link for the same:
https://issues.apache.org/jira/browse/OFBIZ-11035

Soon, I will add a patch for this. Suggestions are most welcome. Thanks!
--
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com


On Wed, Mar 20, 2019 at 4:01 AM Scott Gray <[hidden email]>
wrote:

> Hi Rishi,
>
> Thanks for taking a look!
>
> My only concern with using runAsUser would be that recurring services
> typically use the "system" UserLogin and using this approach might require
> multiple UserLogin/UserPreference records if there are different recurring
> services using different timezones.
>
> Also it should be fine to use RunTime data, as of now I could not see no
> > issues with that. The only thing is not possible is if system requires to
> > run a service always on specific time zone values and runtime could have
> > different values.
> >
>
> Yeah I think I don't like the RuntimeData idea after thinking about it, an
> opposite use case to my one might cause problems, e.g.:
> I want a report to run at midnight UTC every night but I want the
> timestamps converted to Pacific Time because that's where my users are so I
> would like to use timeZone "America/Los_Angeles" or similar for the service
> context.
>
> So I think unless other ideas come along, my preference would be for adding
> a new field to JobSandbox.  I'll create a ticket within the next few days
> and try to come up with a better field name.  Maybe "recurrenceTimeZone",
> seems clear and somewhat concise.
>
> Thanks
> Scott
>
> On Tue, 19 Mar 2019 at 22:24, Rishi Solanki <[hidden email]>
> wrote:
>
> > Hello Scott,
> > Can we think of using JobSandbox.runAsUser='myuser' and UserPreference.
> >
> > <UserPreference userLoginId="myuser"
> > userPrefGroupTypeId="GLOBAL_PREFERENCES"
> userPrefTypeId="defaultTimeZoneId"
> > userPrefValue="UTC"/>
> >
> > Also it should be fine to use RunTime data, as of now I could not see no
> > issues with that. The only thing is not possible is if system requires to
> > run a service always on specific time zone values and runtime could have
> > different values. So having value in database makes sense to me, and okay
> > with #1 of having it on JobSandbox level.
> >
> > I proposed UserPreference so that no field added with possible solution
> and
> > we can achieve it. Could not think of any side effect as of now if we use
> > it only for schedule, in case the same can be use for different purpose
> > while log in, then it may have several side effects.
> >
> > Best Regards,
> > --
> > *Rishi Solanki* | Sr Manager, Enterprise Software Development
> > HotWax Systems <http://www.hotwaxsystems.com/>
> > Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center,
> > Indore,
> > M.P 452010
> > Linkedin: *Rishi Solanki*
> > <https://www.linkedin.com/in/rishi-solanki-62271b7/>
> > Direct: [phone]
> >
> >
> > On Tue, Mar 19, 2019 at 10:56 AM Scott Gray <
> [hidden email]>
> > wrote:
> >
> > > Hi all,
> > >
> > > Trying to decide on the best way to define a temporal expression for a
> > > recurring job where the temporal expression should be evaluated using a
> > > timezone other than whatever the default timezone is for the system.
> > >
> > > Use case is having a system that runs on UTC time, but needs to send a
> > > report at 5pm Pacific Time everyday regardless of whether or not
> daylight
> > > savings is in effect.
> > >
> > > I see two options:
> > > 1. Add a field to JobSandbox such as tempExprTzId (or better name!)
> > > 2. Use whatever timezone is available in the RunTime data service
> context
> > >
> > > #2 seems simplest but I'm not sure if there's scenarios where the
> service
> > > should be run with one timezone while the recurrence should be
> scheduled
> > > based on another?  I can't think of any.
> > >
> > > Regards
> > > Scott
> > >
> >
>

[Craig Parker]

I've left directions for myself to get OFBiz up and running on an Ubuntu
machine, but I'm missing something. ./gradlew ofbiz is giving me no
output, but isn't starting up either. I can't remember where I saw
documentation for showing different output.

[Swapnil M Mane]

Hi Craig,

This issue could be related to your JDK version.
Can you please share the details on which OFBiz and Java version you are
using?
Also, please refer to this mail thread [1], this might help you.


[1] https://markmail.org/thread/iuxnioqiijhrkukp

- Best Regards,
Swapnil M Mane,
ofbiz.apache.org



On Tue, May 28, 2019 at 2:19 AM Craig Parker <[hidden email]> wrote:

> I've left directions for myself to get OFBiz up and running on an Ubuntu
> machine, but I'm missing something. ./gradlew ofbiz is giving me no
> output, but isn't starting up either. I can't remember where I saw
> documentation for showing different output.
>
>
>
>

[Craig Parker]

I threw the newest I found in the repositories (11) but I'll try 8.


On 5/28/19 12:38 AM, Swapnil M Mane wrote:

> Hi Craig,
>
> This issue could be related to your JDK version.
> Can you please share the details on which OFBiz and Java version you are
> using?
> Also, please refer to this mail thread [1], this might help you.
>
>
> [1] https://markmail.org/thread/iuxnioqiijhrkukp
>
> - Best Regards,
> Swapnil M Mane,
> ofbiz.apache.org
>
>
>
> On Tue, May 28, 2019 at 2:19 AM Craig Parker <[hidden email]> wrote:
>
>> I've left directions for myself to get OFBiz up and running on an Ubuntu
>> machine, but I'm missing something. ./gradlew ofbiz is giving me no
>> output, but isn't starting up either. I can't remember where I saw
>> documentation for showing different output.
>>
>>
>>
>>