Geoff Worboys wrote:

> Lester Caine wrote:
>>> My point is that if you store a timestamp including it's
>>> time-zone you can have your cake and eat it too!
>
>> NO
> ...
>> Saving ISO timestamps with a time is pointless unless you
>> also know the location that relates to that timestamp.
>
> Anything you can do with a normalised UTC timestamp you can
> also do with an ISO timestamp. The reverse is NOT true.
>
> The reason is simple: With an ISO timestamp that includes the
> time-zone you can re-calculate UTC anytime you need it. With
> only a UTC timestamp the original time-zone detail is lost and
> cannot be regained.
>
>
> There is an element of truth to also needing the location to
> make good use of time-zone detail... at least for some
> applications. However I can give you two examples where just
> having the time-zone adds meaning:
>
> . A photo of the sun on the horizon, location unknown.
> Is it sunrise or sunset?
>
> . When I am conversing with someone by email I often
> reveal the RFC822 headers to see what time-of-day is
> happens to be where they are. Whether it is getting
> late or whatever. I may even know their location but
> cannot be bothered looking on the relative time-zones
> and whether it is daylight savings there etc.
>
> In either of these two situations an already normalised to
> UTC timestamp cannot help me, the real "time-of-day" detail
> is already lost. Whereas a timestamp that has preserved the
> original time-zone offset (ISO8601) is ideal, it tells me
> BOTH the time-of-day at the source AND how to convert that
> time to UTC if necessary.

No argument with the logic - for handling current day situations - but
try displaying a 6 month calendar in 'local time' just using the timestamp.

The difficulty is that ISO8601 is not a solution to the real problem. So
SIMPLY using timestamps is not the total answer. And more important when
perhaps checking back on even email activity you may be an hour out on
when you think an event happened - which could be important? ( A
customer says they told you something 9AM local time the previous month
when actually it was 10AM and you did meet the contract time-frame? )

It has taken some time to convince some people that reliance on 'TZ' as
a means of identifying a clients local time is simply inadequate and
that we need the BROWSER to understand DST rather than simply saying
'The time now is xxx' but I doubt that correcting the real problem will
happen, so we need a hack to identify WHERE a timestamp is if using a
timezone offset! I'm probably just nit picking, but having spent several
months unravelling the calender display function in bitweaver the real
solution to the problem came when the original 'flexibility' of using TZ
was scrapped and replaced with having a client identify their DST zone
properly. (Adding to the fun, times were stored in server local time
which made it even more fun! ) Anonymous clients MAY get wrong calendar
information for half of the year - there is nothing that can be done
about it because we don't know what their local time will be in 6 month.
To do the job properly in a lot of cases you need more information than
ISO8601 provides and simply saving TZ in a timestamp may actually cause
more problems that it 'cures'?

Which is why - personally - I prefer simply to drop the TZ, leave the
timestamp as simple UTC and then provide the proper data on where the
timestamp was located ;)

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php