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 <[email protected]> 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 >
