> Geoff,

> I agree but want to suggest that if it is necessary for a
> system to commonly convert datetime values between timezones
> that storing the values as UTC is the only real solution.

...

My point is that if you store a timestamp including it's
time-zone you can have your cake and eat it too!

For comparison purposes normalisation remains possible while
for information purposes the original information remains
available. eg:

What time of day was it when this photo was taken _at_ the
location of the photo - not where my computer happens to be
sitting some indefinite time later.

The timestamp class I developed for this project internally
stores the date/time data as UTC, to optimise comparisons etc,
but also retains the time-zone in order that it can reproduce
the original input without loss of information.

Storing these values as ISO8601 strings, combined with our
custom collation, the comparisons and indexing at the FB server
all work as expected (compare value as normalised to UTC), but
without the loss of data that is normal to the FB timestamp
data-type.


The fact that time-zone details change over time makes it even
more critical to store the actual time-zone relevant to the
data... otherwise, in several years time, you may find it
difficult to convert a UTC time back to the time-of-day of the
original data even if you did store the source location.

The time-zone is is what tells you what time of day it was
considered to be at that location in that period in history.
Your very correct information about the variability of time-
zones simply proves that you should not discard it until you
are certain you wont ever need it again.

--
Geoff Worboys
Telesis Computing