I looked at this and the current code is certainly wrong. The timezone
offset of a Timestamp (deprecated method!) returns the offset of the
JVM's default timezone always. We should indeed be passing the target
calendar and using that.
I've added that change to my patch. Interestingly none of theregression
tests fail with it changed; we're very short on tests that actuallytest
the with-Calendar code..
Well, I actually think this little change is more of the problem thananything else.
I don't understand what you mean -- are you saying we shouldn't change this?
No, I think this may be the bug that causes it to fail currently. Not that it shouldn't be overhauled. But this one is
probably the most significant "bug"
Did you manage to cobble together a patch for me to test ?
I'll send you a current snapshot in an hour or so. I got sidetracked into trying to work out the semantics of getDate() and getTime() on a timestamptz, still haven't found an entirely satisfactory solution..
OK.
-O
---------------------------(end of broadcast)---------------------------