|Subject||RE: [firebird-support] Re: Daylight saving|
> I was very close to posting a similar issue yesterday. OurHi Adam,
> 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.
> 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.
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
Comvision Pty. Ltd.