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

Hi Adam,

Thank you for your suggestions, you have reinforced what I was considering.
Thus, I definitely will store GMT and local time, as one of the main
specifications for the DB app is that " A user must be able to retrieve
events based on local time and date" that's the only way a user will know if
the "event" took place at 23:15 local time before daylight savings for
example, or 23:15 local time after daylight saving, as well as giving the
choice to view the event she/he is interested in.


Apart from the increase in accuracy regarding time-stamps, I wounder what
other goodies are in FB V2?



Once more thank you

daniel

____________________________
Comvision Pty. Ltd.

www.comvision.net.au