Subject AW: AW: [firebird-support] Timezone again
Author Steffen Heil

> But that's exactly what it does. Firebird doesn't really do anything with
timestamps. They're just two-part integer numbers that can be compared for
equality, less than, etc. In some cases it has to compare it to strings, and
when that happens it does a simple string-to-binary or binary-to-string
conversion of the actual value, no matter what timezone the server is
running in or what timezone the string was formatted in, etc.


> But the FB server does take the timestamp from the machine it is running
on, so assuming you don't change that machine's timezone in an ad hoc
manner, the timestamps stored in that database WILL allow correct
ordering of information. But I still think generators and sequence numbers
are better for that purpose, because it just might happen that two events
happen in such tight sequence that they get the same timestamp. I wouldn't
want to rely on that not happening, anyway.

Only if you don't use CURRENT_TIMESTAMP.
Ohterwise, you CANNOT correctly order events.
For example, assume a linux server is running MET/MEST and storing an event
at 125643239 (unix time) and on event one second later at 125643240 (unix
Then firebird will sort them in the wrong order, as the first encodes to
55129:107990000, while the second encodes to 55129,72000000.
Note that the OS-time advanced, but firebirds interpretation of it does not
match this order.

> Do you need to be able to compare timestamps between databases from
different machines (with potentially different timezones)?


> Do you need to be able to migrate your database between machines (with
potentially different timezones)?


> You could always store the server machine's timezone somewhere in a config
table and have all timestamps stored in that timezone. You can then safely
use current_timestamp.

No. See example above.

> between its desired timezone and the server's. Everywhere. But you could
write a udf for it.

This sounds like a solution, except that having a UDF to simply return
REAL_CURRENT_TIMESTAMP() sounds strange.


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