Calendar weird reaction with wrong Timezone about apps HOT 14 CLOSED

The issue is caused by the following:

We click on the calendar (at some date/time). Fullcalendar.js generates an event, and creates a Date object with the correct values. Those values are in the timezone of the BROWSER.

So if you click on 10 oct in monthview, you will have '10 Oct 2012 - 00:00 GMT+02' (thats when browser is in GMT+02).
Now the Date object is converted into a Unix timestamp (which is always UTC), and this is passed to the new.form.php ajax script.
Here we convert the timestamp into a PHP DateTime object, and convert it to the timezone set in ownCloud.

Ofcourse, if this is different then the browser timezone, you will receive weird values.

I think this can be solved by letting the calendar.js pass the Date '10-10-2012T00:00:00' instead of a unix timestamp.
In the PHP code we can then create a new DateTime object from format. This should work correct if browser and ownCloud have different timezone settings.

@georgehrke What do you think? I can fix the patch for this.

from apps.

No matter how often date time info is converted (from "Wed Oct 10 2012 00:00:00 GMT+0200" to unix timestamp "1349820000" to some timezone set on the server "Tue, 09 Oct 2012 22:00:00 GMT"), the information specifies one particular point in time. Nothing wrong with this.

If you start to cut off the timezone info, things will start to become weird. The information will no longer specify a particular point in time, but a point in time in the current timzone. Whatever timezone this may be. What timezone will be used by owncloud if the user didn't specify one? The server's timezone? What server? Aren't we in a cloud?

from apps.

Ok i understand we have to make a choice.... maybe we have to take Oc timezone and warn the user if the browser and oc timezone are differents ....

but it's really disturbing to click on 10:00 on the Cal and receive a form with 8:00 ...

from apps.

It's already part of my calendar roadmap for ownCloud5. I will add a js that gets the timezone and send it together with the time to the server.

from apps.

In general time zone should only matter on the presentation layer and it's a user setting (either implicit or explicit).
Within the data model a time stamp should be stored time zone neutral - using UTC in general would be a good strategy.

Generally speaking: we should not care where the server is located - and to some extend we should make no assumptions on where the client (browser/mobile device) are located.

from apps.

That's exactly the way I want to implement it :)

from apps.

Excellent!
It was not clear from your previous message. (Or did I miss anything anywhere?)

THX

from apps.

No, you didn't miss something :)

from apps.

I agree, it's a representational matter. But currently, there are still two sources of information: The timezone information stored in the user's profile server side, and the timezone information you can get from the user's browser. Which one are going to use?

from apps.

I'd suggest to use the client's (browser/mobile device/PIM) time zone.

Do we need to store the time zone in the user profile for any reason?

from apps.

As I already wrote ;) - I am going to use jstz to get the timezone set in the browser

from apps.

What about caldav?
Do you need to care of this as well or will the clients take care? - just asking ....

from apps.

Should be the responsibility of the client. At least as long as the caldav dates contain tz information (I'd stick with UTC for caldav).

User profile tz information seems to become obsolete... Can't think of a use case for it.

from apps.

So, @georgehrke I suppose this is fixed? Closing this, please reopen if it’s not fixed yet.

from apps.