Re: Comparing date values

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Comparing date values

Colin Paul Adams
>>>>> "Michael" == Michael Kay <[hidden email]> writes:

    Michael> The best advice one can give on timezones is: make them
    Michael> explicit.

I can't really agree with this. An unzoned value has a natural and
useful interpretation as the current local timezone (the obvious use
being running the same stylesheet at different locations around the
world - if this is pre-compiled, then having the implicit timezone
defined as at compile time wrecks this).

    >> 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
evaluation.
So far I've not seen any problems.

Do you have some test cases for these bugs?
If so, I'll let you know if this scheme fixes them.
--
Colin Adams
Preston Lancashire


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help
Reply | Threaded
Open this post in threaded view
|

RE: Comparing date values

Michael Kay
>
>     >> 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
> evaluation.

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
different timezones.

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
the application.

Michael Kay




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
saxon-help mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help