Hi

> > Fine, as expected. (Not that I had preferred it as more standard

timestamp such as milliseconds sice 1970 or such.)

> Sorry. There's some merit to supporting the SQL standard and providing

sub-millisecond time.

I know and I surely didn't want to suppose any change. I just wondered this
this was a IMHO bad design decision in the sql standard...

> > This is really bad. I (and propably most of other users) thought that

always inserting information into logging tables with CURRENT_TIMESTAMP
would allow correct ordering of information. But in fact, IT DOES NOT... I
consider this a bug. (Propably less in the implementation but in the
specification.)

> May I recommend generators?

They cannot be a replacement, as those logging tables of several servers
need to be combined offline afterwards. They could assist to interpret which
timestamp is actually more recent, hoping that there is at least one record
every hour such that the information is not ambique..

However, what's the point in sub-millisecond precision, if the hour is not
deterministic?

> > 5) Can the timezone be fixed (per database?, per server?) ?
> The standard provides, but to my knowledge Firebird does not implement a

way to do that.

I think we have a misunderstanding here. I was hoping of some configuration
file parameter to tell firebird to store timestamps in a certain timezone.
Not how to interpret data inside the database, but for CURRENT_TIMESTAMP and
string parsing.
I just don't like the fact, that whoever wants to use a database to use
correct timestamps has to configure the OS of the server in a certain way.
If there is any other service on the server who has the same restriction you
need two servers for basically 5 lines of code.

But that doesn't matter any more. Firebird does not have such a switch and I
have to live with it or contribute a patch. If I knew more C/C++ I would
propably do so, but I am more in java.
Even despite the fact that I will propably have to abandom timestamps
altogether and use INT64s as replacements, I am a really big fan of firebird
and I respect all the good work done to it.

> Oh great, lets have a configuration parameter that changes the meaning of

stored data! Instead, lets see if one of the changes for version 3 could be
the time zone sensitive timestamp and time.

Not at all. I suggest to add a configuration parameter to FIX the meaning
of stored data. Right now, the data read from the database is dependent of
other configuration parts of the system. 04:00 PDT is simply not the same as
04:00 GMT! If there was a database dependent Timezone switch, the database
could be copied (backuped/restored) to any other system, still preserving
it's meaning. Right now I have to hope, that the timezone matches!


Regards,
Steffen



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