Subject | AW: AW: [firebird-support] Timezone again |
---|---|
Author | Steffen Heil |
Post date | 2009-11-05T21:16:27Z |
Hi
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.
Fine.
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
time).
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.
Yes.
Yes.
use current_timestamp.
No. See example above.
This sounds like a solution, except that having a UDF to simply return
REAL_CURRENT_TIMESTAMP() sounds strange.
Regards,
Steffen
[Non-text portions of this message have been removed]
> But that's exactly what it does. Firebird doesn't really do anything withtimestamps. 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.
Fine.
> But the FB server does take the timestamp from the machine it is runningon, 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
time).
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 fromdifferent machines (with potentially different timezones)?
Yes.
> Do you need to be able to migrate your database between machines (withpotentially different timezones)?
Yes.
> You could always store the server machine's timezone somewhere in a configtable 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 couldwrite a udf for it.
This sounds like a solution, except that having a UDF to simply return
REAL_CURRENT_TIMESTAMP() sounds strange.
Regards,
Steffen
[Non-text portions of this message have been removed]