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 <rishisolan...@gmail.com> 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: +91-9893287847 > > > On Tue, Mar 19, 2019 at 10:56 AM Scott Gray <scott.g...@hotwaxsystems.com> > 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 > > >
