Subject | Re: [firebird-support] Timezone support? |
---|---|
Author | Lester Caine |
Post date | 2011-07-27T07:09:45Z |
Thomas Steinmaurer wrote:
Run the servers 'UTC' ... the 'location' data can go in a separate table. You
THEN have the option of displaying times local to your client, local to the
'event' location, and with the correct daylight saving offset for either of
those! Trying to store times with 'local server time' and THEN converting simply
does not work ...
Reason for the separate 'location' table is that if using web browsers as client
access, their 'TZ' flag is no use if the client IS in a daylight saving area ;)
--
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
>> What type of timezone support does FB have?Seconded ...
>>
>> For instance, is there a function to convert between two time zones?
>
> I'm afraid there is no timezone support in Firebird's date/time
> datatypes. CURRENT_TIMESTAMP etc. gives you the local time of the
> machine where the Firebird server is running.
>
> I had been in a situation where timezone support could have helped,
> namely when comparing captured mesurement values of sensors, which in
> practice can be spread around different time zones, in respect to: "for
> a given time point and not clock time".
>
> What we did is that each received mesurement value had a UTC timestamp
> (basically the UTC timestamp from the devices out in the field) with the
> timezone (and winter/summer time) offset in a separate field. This way,
> we have been able to compare values in a DWH for a particular UTC
> timestamp and/or, if we like, for a given clock time, by taking the
> offset into account.
Run the servers 'UTC' ... the 'location' data can go in a separate table. You
THEN have the option of displaying times local to your client, local to the
'event' location, and with the correct daylight saving offset for either of
those! Trying to store times with 'local server time' and THEN converting simply
does not work ...
Reason for the separate 'location' table is that if using web browsers as client
access, their 'TZ' flag is no use if the client IS in a daylight saving area ;)
--
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