Hi Daniel,

I was very close to posting a similar issue yesterday. Our
application is multi-site, hosted on a Terminal Server. It is
possible and quite likely that different users within the same
database are connecting from different timezones, and differing
daylight savings dates which makes scheduled events interesting. For
example, we may need to run something at 4am in the morning, but that
is really 6am where the server is.

Firstly, I found a link for Delphi anyway with some useful
information and routines.

http://www.thedelphimagazine.com/samples/1175/1175.htm

Secondly, you should consider storing the times in GMT so you have a
reference point, and you should be able to know the location the time
was recorded at so you can convert it to local time.

Thirdly, Terminal server contains a setting in the registry (I forgot
where it is) that allows it to adjust the clock for each users
settings to their local timezone read from the client PC. This is
really useful.

For audit information, do not store it in local time (unless you
store both gmt and local time). Local time is ambiguous around
Daylight Savings and across different timezones. GMT remains constant.

You may also want to consider whether you trust the clock on the
client PC or whether you use current_time variables within Firebird.
Remember also that if you roll back a transaction, if the audit is in
the same transaction, the audit information will also be rolled back.

I am also not sure about how fine a grain you can get out of the
current_time variable (does it return milliseconds etc?). I think I
read somewhere you need to write a UDF to get time in milliseconds.
(If you actually care to that accuracy)

Hope that is of some help.

Adam.



--- In firebird-support@yahoogroups.com, "Daniel Jimenez"
<d.jimenez@c...> wrote:

> Hi everyone,
>
> In the near future we are to develop a DB app, which must keep a

very

> accurate audit trail, which as you can imagine includes date and

time. Thus,

> their exist the potential for corruption (for that one hour when

time

> travels back for daylight savings), so before reinventing the

wheel, I would

> really appreciate if you could share your experience or suggestion

regarding

> this.
>
> Thank you in advance
>
> daniel
>
> ____________________________
> Comvision Pty. Ltd.
>
> www.comvision.net.au