From: Michael Kay <mike@sa...> - 2005-09-12 22:40:24
> >> Wouldn't it be better to create it in the
> >> transformer, like you do for the current-datetime?
> Michael> Yes, this was a deliberate choice, because the
> Michael> alternative approach was causing a lot of problems (and
> Michael> bugs).
> I don't think the problems are very severe.
> I've approached this by adding a dependncy on the implicit timezone
> for unzoned values, suppressing pre-evaluation for functions that
> might use it, and checking for either expression having a dependency
> on the implicit timezone, before going ahead with compile-time
You can solve the problems of compile-time evaluation that way. Another way
is to generate code that incorporates the implicit timezone as an explicit
operand of the expression.
The other major problem is keys: Saxon tries to ensure that the index
supporting a key can be shared by multiple (concurrent or consecutive)
transformations, and since the result of equality comparisons depends on the
implicit timezone, an index can't be shared by two transformations in
Again, the problems are soluble, but at the cost of a fair bit of effort and
testing of rather obscure cases. I just decided it wasn't worth the trouble,
at least for the time being. I suspect that some of the RDB vendors are
going to be even more restrictive, requiring the implicit timezone to be
defined at database creation time.
Remember that the dateTime handling doesn't deal properly with summer time
changes anyway: anyone doing scheduling of telephone conferences or
international flights is going to have to do their own timezone handling in
Get latest updates about Open Source Projects, Conferences and News.