Planetwide UTC isn't happening.

So having given that up, it's your choice as to how you store the information you need with your calendar. What is clear is that in order to deal automatically with changing DST rules a meeting needs to be coded with it's local timezone known to determine to which meeting a change needs to be made if any. How you do that is an implementation choice.

I am not suggesting a change in how dates are exchanged between agents. Both UTC dates and local time dates have their advantages and disadvantages.


On 05/09/2013 5:11 PM, Lester Caine wrote:
Patrice Scattolin wrote:
But you are right, in order for that to happen correctly both the time and the
timezone has to be noted so that a correction can be applied properly.

I've never subscribed to including timezone data IN the date, that is always 'UTC' but if the timezone field is 'null' then the location field is used to provide a timezone and the time is assumed to be 'local' to that. As has been said, where systems only return a time offset then time zone has to be calculated a different way anyway.

Just spoken to one of my confference customers on another matter and asked them the question on a time change at a venue. The answer was that they would have to maintain the UTC times of the event, both for travel arrangement and also they normally have a live link to another country ... but they hopped that it never happens :)



--


Oracle Email Signature Logo
Patrice Scattolin | Principal Member Technical Staff | 514.905.8744
Oracle WebCenter Mobile applications
600 Blvd de Maisonneuve West
Suite 1900
Montreal, Quebec