Steffen Heil wrote:

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

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

>
>
>>> 5) Can the timezone be fixed (per database?, per server?) ?
>> No.
>
> Bad.

The standard provides, but to my knowledge Firebird does not implement
a way to do that.

>
>
>> What's needed is to add two new types to Firebird - TIMESTAMP WITH
> TIMEZONE and TIME WITH TIMEZONE. The timezone has to be stored with each
> value, since, as you've demonstrated, most of us live in two different
> timezones, which vary with the season.
>
> No. I would even consider storing timestamps together with timezones a
> mistake. For me it smells like storing a radix together with integers. The
> database should store information, not display formatting hints.

First, the solution I described works. Second, it follows the SQL
Standard, which is a good thing. Arbitrary differences from the
standard make adopting a new database harder. Third, time zone is
not a formatting hint, it affects the real meaning of the stored
information. And finally, sometimes you store timestamps as MET
and sometimes you store them as MEST.

>
> Could it be an option to add an configuration parameter to firebird.conf to
> force firebird to use a specific timezone for internal things like
> CURRENT_TIMESTAMP and parsing and string concatenation?
>

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.


Cheers,

Ann