Allow Corb to specify the timezone for the request. about corb2 HOT 2 CLOSED

What is the issue/scenario that this helps address? Do we have users evaluating/parsing dateTime string values (without timezone) that are being evaluated as GMT and they want them evaluated as if they were in another timezone (e.g. America/New_York)?

• We could obtain the CoRB client's TimeZone using TimeZone.getDefault() , and ensure that the TimeZone is set in the invokeModule().
• Or were you thinking that the TimeZone ID would be explicitly specified as a CoRB option that is parsed with TimeZone.getTimeZone() and set in the TaskFactory.setupTask() for all of the Tasks for that job.
• Would we want TimeZone to always be set for XCC requests, or only when enabled and/or explicitly set via options?

from corb2.

Hi Mads,
This is not a critical issue as we have an alternative, thought not elegant. Basically, when a query is executed through xcc on ML server, it gets the time zone from dynamic context of the request. Unless it is specified, XCC requests uses default timezone of JVM.

So, when you do fn:implicit-timezone() or fn:adjust-dateTime-to-timezone() in your queries, it always get the CoRB client's timezone and there is no easy way to force it always use the server timezone. This can be problematic as same code run from two timezones or daylight vs non-daylight savings time may behave differently. I found the problem when I was troubleshooting a job failure for another team here. The alternative it is to either hard code the timezone in xquery or pass as an external variable to prevent daylight savings shift.

Ideally, we should have an 'option' to always use the server's timezone (if ML allows it). But if Corb allows us to set the timezone, we don't need to hard code or make adjustments in the query/code.

from corb2.