Subject | Re: suggestions for timestamp / timezones |
---|---|
Author | Adam |
Post date | 2004-12-15T13:07:27Z |
--- In firebird-support@yahoogroups.com, "Peter Chaisty" <peter@c...>
wrote:
span several timezones. For example, Sydney, Adelaide and Perth in
Australia all have different timezones. Also make sure you understand
the concept of Daylight Savings Time, as that will adjust the GMT
bias, Sydney and Brisbane are in the same timezone, but for a couple
of weeks there is an hour time difference.
If the clients are windows clients, the information about the GMT
offset can be read from the registry. If you are using Delphi, read
up on the TTimezoneInformation. It may be easier to just store both
times, it just depends on what you sort of database size and
performance constraints you must work with. Searches may need to be
done against both GMT time and local time, and an index can't be used
on one if it is calculated from the other rather than a real field.
Adam
wrote:
>You will probably need more than a country code, larger countries
> Hi
>
> I am looking at storing data on a central server which may be in a
> different timezone to the client applications.
>
> I am considering setting the server time to GMT and maybe storing a
> countrycode for each client store operation in order to be able to
> convert back to clients local time.
>
> Has anyone else done this and can offer any suggestions or ideas ?
>
> Rgds
>
> Peter
span several timezones. For example, Sydney, Adelaide and Perth in
Australia all have different timezones. Also make sure you understand
the concept of Daylight Savings Time, as that will adjust the GMT
bias, Sydney and Brisbane are in the same timezone, but for a couple
of weeks there is an hour time difference.
If the clients are windows clients, the information about the GMT
offset can be read from the registry. If you are using Delphi, read
up on the TTimezoneInformation. It may be easier to just store both
times, it just depends on what you sort of database size and
performance constraints you must work with. Searches may need to be
done against both GMT time and local time, and an index can't be used
on one if it is calculated from the other rather than a real field.
Adam