Steffen Heil wrote:

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

I agree with that. In the first instance, TIME WITH TIMEZONE is actually
utterly meaningless since one REQUIRES a date with it in order to
identify the daylight saving offset that needs applying. Only times that
do not have a daylight saving offset would be accurate.

I think that there are actually two ways of thinking here ...

Either the system does not NEED TIMEZONE - as is the case where all
users are actually in the same timezone, and 9:00 in winter is the same
as 9:00 in summer. In this instance Firebird is simply correct and works
fine. NOW is now on the server. Many 'projects' don't bother with
timezone and work.

The second situation has users in a different timezone, then management
of timezone offset becomes a major headache. BUT only if one makes it
such! As I've indicated before, in this instance ALL you should store in
the DATESTAMP is a UTC offset date/time, since that is the only thing
that is accurate for everybody. In this case Firebird again is working
correctly and just needs the server to be set to UTC - WHICH IS SHOULD
BE FOR INTERNATIONAL WORKING! Distributing servers across timezones
needs to have a single accurate time and saving the server timezone to
the saved times just does not work !!!

It is the client interface that needs to handle offsets - and that can
only be done if you know the clients offset in the first place! Adding
events to the database needs to know the accurate time summer or winter
for that client and that is not available by any automatic means. So if
one wants to know the TIMEZONE then its the timezone of the client ( or
off the server ) and it should be stored in an extra field, but one
needs to ask WHY that information is needed? You either save the id of
the user ( or of the server ) that created the record and then you can
DISPLAY the date in one of a number of offsets depending on what you
want to display?

And if you want Unix epochs - just use a BIGINT and the library that
comes with your deployment environment. Although it would be nice if
FlameRobin could selectively display them as times ;)

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php