Hi

> > The second line shows my problem: There are cases, where the encoding is

not bijective.

> But which ones?

Sorry, for sure I ment "third line"... I think we already agreed on that.

> Current state of affairs with timestamps in Firebird is very similar to

the situation when people have their databases with NONE charset - as long
as your client and server have same settings and you do not change anything,
things work like a charm.

Here I disagree. If every component is working in CET/CEST (german default)
then I loose information a get a wrong order on records!!!!
So, even if everything on the client AND server side is CET/CEST, I still
need to pass an UTC-Calendar to the setTimestamp/getTimestamp functions to
be sure not to loose information? That's not nice...

> If the timestamp in Firebird would store timezone information as well, it

would be like an UTF8 charset.

I don't even think, firebird should store timezone information. Timezones
exist to give humans a easier notation. Such that everybody on the planet
may recognize 21:00 as "somewhen in the evening". However in the database
the notation does not matter, it just stores facts, that is precise time
information. Storing timezones together with timestamps would be as storing
radix information together with integers. It is the job of the client to
parse and display timestamps, not the servers. (Except when there is
conversion between types or things like day or month extraction, but these
need to be handled in the conversion commands, not in the data types.)

> Well, if that solves your issue, why not?

Because I make my webapplication fail very hard, if any other webapplication
creates any calendar object earlier. In fact tomcat itself might do so. I
have only tested this with local testcases so far...

> At the moment it is obsolete. However there is another quite expensice

place: Calendar c = (Calendar)cOrig.clone();

> I need this for translation, but I do not know if I am allowed to modify

the specified calendar...

I've seen that, but I don't know if it is allowed.
I've just learned the hard way, that SimpleDateFormat's loose their
timezone, even set "setTimezone" was called, if they find a timezone
specification in a parsed string... Therefor I would have preferred 2
classes SimpleDateFormatter and SimpleDateParser...

> That can be fixed - that is not a big issue here. I could extend the

FirebirdResultSet and FirebirdPreparedStatement interfaces with
getRawData(int) and setRawData methods.

That would be nice.
For completeness, please also add getRawData(String).

> What about adding "parallel" methods starting from the

FirebirdPreparedStatement and FirebirdResultSet, additional setters and
getters for FBDateField, FBTimeField and FBTimestampField, which then
call your extensions of XSQLVAR code? That could be added to Jaybird.

I somewhat don't like that idea.

If fact, I would add another database parameter, just like
DatabaseParameterBufferExtension.TIMESTAMP_USES_LOCAL_TIMEZONE, say
TIMESTAMPS_STORED_IN_UTC..
The getters/setters without Calendar argument would just call the UTC
functions, while those with Calendar objects would also add the raw offsets
of the respective timezones.

On the long run, this seems to be the only sensful way.
I am just not suggesting this as replacement because it would break about
any existing database (that is not using UTC).

> Then two possibilities exist - one is to add some connection parameter

that would make the "normal" setTimestamp methods to delegate to
setTimestampUTC, or create a thin proxy layer that would do this delegation
transparently. I prefer latter.

This would make code database dependent. Then you could also use the
existing classes and always pass a utc-timezone calendar. Except for
execution times this should be the same.
But I don't want to push such problems into client code, some on which I am
not even in control of.


Regards,
Steffen



[Non-text portions of this message have been removed]