Lester Caine wrote:

>> An alternative, if your client application can be made to
>> support it, is to use timestamps with embedded time-zones
>> stored as ISO8601 strings in the database.

...

> DAYLIGHT SAVING?

Yes, AFAIK most systems that deal with time-zones incorporate
daylight-savings into the code... usually by assuming the
operating system can tell it the local time-zone in much the
same way they rely on it to tell them the local or utc time.

The point is to record the timestamp as it was to the person
or process that saved the timestamp. To normalise out the
time-zone is to lose part of the original/source information.
In some applications it does not matter, in some it does.

While a separate TZ can be used (and must be where client
facilities still retain only primitive timestamp support),
being forced to keep it separately is like having to keep the
date and time parts of a timestamp separately. It is all
part of the same data, separate storage is an implementation
artifact not a design artifact.

--
Geoff Worboys
Telesis Computing