However what I'm actually seeing is as follows.

(1) Set a Linux machine to "Brazil/East". Check this using the "date"
command line command.

(2) Confirm that

select CURRENT_TIMESTAMP from rdb$database

does report the Brazilian local time as expected.

(3) Next, I've got a table with a TIMESTAMP column called TIMEDATESAVED.
The BEFORE UPDATE trigger includes

new.TIMEDATESAVED = CURRENT_TIMESTAMP;

When I modify a record in that table I find that TIMEDATESAVED gets set
to the the current UK wall clock time, *not* the Brazilian time as at
(3) above. That's looking at the field both using a SELECT from isql and
using Database Workbench, both giving the same result - I haven't made
any attempt to see what the actual binary on the disk is.

------------------

So it seems from these experiments that CURRENT_TIMESTAMP sometimes
reports the Brazilian time and sometimes the UK time.

I just don't believe this. Can anyone make any other suggestion as to
what is going on?

On 13/01/2017 11:21, Tim Ward wrote:
> On 12/01/2017 14:09, Tim Ward wrote:
>> Sorry if this is a really basic question, but some time spent
>> searching has failed to find for me the definitive detailed
>> documentation on exactly how Firebird handles time zones (I'm
>> particularly interested, to start with, in using CURRENT_TIMESTAMP to
>> create a value in a TIMESTAMP field, and later reading it out and
>> using it to display in a UI, but that's only to start with).
>>
>> Can someone point me in the right direction please?
>
> So to summarize the replies (thanks all):
>
> (1) Firebird does not attempt to do anything at all with time zones,
> and has no concept of UTC.
>
> (2) CURRENT_TIMESTAMP and its relatives ask the operating system for
> current wall clock time.
>
> (3) This is what gets stored and read back out of tables, with no time
> zone manipulation.
>
> (4) So if for example CURRENT_TIMESTAMP is called when it's 0700 UTC
> but 0500 local wall clock time as configured in the operating system,
> then the value will be 0500 at all times and places in Firebird
> (unless arithmetic is done in it by explicit application code).
>
> (I'm trying to understand the behaviour of an existing system here,
> not design anything new.)
>


--
Tim Ward