Leyne, Sean wrote:

> Lester,
>
>>>> 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!
>> NO
>>
>> If you store a meeting as 9AM British Summer Time, and then the
> meeting
>> gets moved to the following week - GMT - The there is no way of
> telling
>> from the ISO8901 timezone stamp that you need also to adjust an hour!
>
> Actually, you can.
>
> Moving the item is not a simple mathematical operation of adding 7 days
> to the current value but also adjusting the timezone portion of the
> date/time based on the UTC offset will be for the same **time of day**
> for the new date.
>
> Consider:
>
> Event time = "2009-03-11T10:00-05:00"
>
> If this event is moved to March 18th, you would need to get the UTC
> offset for 10:00am March 18 (March 18 is UTC-4, daylight saving).
>
> So, the new meeting date/time will become
>
> Event time = "2009-03-18T10:00-04:00"
>
>
>> Saving ISO timestamps with a time is pointless unless you also know
> the
>> location that relates to that timestamp.
>
> That really only matters if the daylight savings rules change and you
> expect the meeting time to maintain the **time of day** context.

Sean - you are missing the point! How do I know that -05:00 is in a
daylight saving area? A large part of the world simple does not bother
and some smaller areas have different rules. ISO timestamps simply
sidestep the fact that their data MAY be wrong for 50% of the year.

--
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