timezone option for current-dateTime()

[Dennis Knochenwefel]

current-dateTime() currently returns a value that is dependent on the runtime system (i.e. the timezone setting in the processor). It would be great if one could set the timezone within a query, for example using a zorba option.

example:
------------------------------------
declare namespace op = "http://www.zorba-xquery.org/options";

declare option op:TIME_ZONE "z";

current-dateTime()
------------------------------------

result:
------------------------------------
2004-05-12T18:17:15.125Z
------------------------------------

[Paul J. Lucas (paul-lucas)]

Is this even true? current-dateTime() is *SUPPOSED* to return a date/time with a timezone from the dynamic context that is independent of whatever date/time/timezone the processor happens to be set at.

This bug was opened in 2009 and hasn't been fixed for 3 years. Does anybody still care?

[Dennis Knochenwefel (dennis-knochenwefel)]

This was supposed to be a feature request, not a bug report.

What you describe is exactly the problem: there is only an *implicit* timezone in the dynamic context (doesn't matter really where it comes from). Yet, there is no way to set an *explicit* timezone. And, yes, I know that I can use fn:adjust-dateTime-to-timezone().

For the user it will be a huge benefit if zorba offers e.g. a global option to set the timezone in the dynamic context explicitly. Then you wouldn't have to adjust each date time to the timezone that you need.

[Paul J. Lucas (paul-lucas)]

So it should set the timezone in the dynamic context -- not ONLY for current-dateTime() ? If it is set in the dynamic context, does anything else change as a result?

[Dennis Knochenwefel (dennis-knochenwefel)]

exactly.

I would expect that it is only allowed to use this option in a main module and that all implicit-timezone-dependent functions change their behavior automatically. More in detail, not only in the main module, but in all dynamic contexts (all library modules etc.). This should be fairly easy to implement, but is a huge usability improvement.

Does that make sense?