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

Hey, that's life. On the last Sunday of October you have the 2:01 am
twice. What is wrong with it? If somebody tells you that event happened
at 2:30 am on 25th of October 2009, can you tell which hour in UTC it
was? Same about switching to DST time in spring...

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

Agree, if you do not have full control of the web server, it is bad
approach.

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

Sure, I was just lazy typing that in previous email.

>
>> 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).

Ok, I will think about this as well, but not sure that I like it.

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

Probably you misunderstood that. The idea is to make it transparently.
In fact you can do this now, only that performance would be not perfect.

Idea is that you create custom DataSource or ConnectionPoolDataSource
and when the connection is obtained, you get the connection from the
underlying data source and wrap it into your dynamic proxy. Then, when a
statement is created you wrap it with another dynamic proxy which
intercepts calls to PreparedStatement.setTimestamp/Time/Date methods and
instead calls the ones with UTC calendar as parameter. Also you watch
the executeQuery and getResultSet methods and wrap them as well in order
to intercept the ResultSet.getTimestamp/Time/Date methods.

The idea of adding new methods into Firebird-specific interfaces was to
use your fast UTC encoding method, not the way of passing the UTC calendar.

Roman