> As far as I understand this, as long as I use setTimestamp/setDate and
> getTimestamp/getDate I should be safe to get the same information back,
> INDEPENDENT of any timezone in the system, java or whatever?

It creates you an appropriate timestamp (e.g. Wednesday, 4th od November
2009 17:49:35.005) for your _locale_ timezone (which for one client can
be GMT+01, for another - GMT+05). If then, you do all computations in
your local timezone and then save time back, it will be the same.

But if in any computation the code starts working with another timezone
without appropriate correction and returns you the timestamp back (e.g.
you export data to a CSV file, send it per email to USA, it is processed
there in local time, modified, returned back, you read it in local
timezone), you might get issues (I think the easiest was the DST
correction which might be performed already on one side but is not yet
there on the other side of the globe).

>> Driver does not apply any particular intelligence here. However, when it
> converts the 8-byte number into Timestamp, it uses the default time zone, if
> other is not specified.
>
> I don't know what kind of notation this is, but if it is similar to javas
> notation ([milli]seconds since ...) then there should not be any timezone
> involved.

The Firebird's timestamp is a double precision number, where integer
part is number of days passed since some "time zero" (not 1970, it has
some DEC history behind), the decimal part is a fraction of the day.
Jaybird makes "new GregorianCalendar()" and then set appropriate
components of date (year, month, day, hour, minutes, seconds,
milliseconds) and performs the DST correction. Then it takes the regular
long time value and constructs appropriate java.sql.Date, java.sql.Time
or java.sql.Timestamp object.

> If it is used, then what for?

It is not used, but I cannot construct a GregorianCalendar instance
without timezone - the default constructor uses the OS settings.

> And: Can I set it globally?

Yes, in the regional settings of your OS. I do not know about any JVM
option to set it.

In your case the issue happens somewhere when your linux box (UTC) sends
data to windows box together with timezone information (or vice versa)
which gets interpreted then and one side performs corrections but also
obtains raw data without corrections... If my mind works correctly,
there should be no issue if data are transferred only in one form
(binary or string) and always go from windows client to linux
application and then into the database.

Roman

Roman