0013804: Timezone Issues with TbSync #6827

Open
Gloirin opened this Issue Jun 9, 2018 · 7 comments

Comments

Projects
None yet
3 participants
@Gloirin

Gloirin commented Jun 9, 2018

Reported by estradis on 21 Mar 2018 19:30

Version: 2018.02.2 Community Edition

This issue is forwarded from another issue at jobisoft/TbSync#45 (comment).

Here is the summary from the other issue:

"Tine will use the LOCAL time of the event in the global view, which is not clever. Thunderbird always calculates the time of the event in the default timezone of the user and only displays the timezone specific time in the edit window (as Tine does)."
...
"The above finding results in "moving events" if the timezone is changed. Which is again a bad idea."
...
"Also, Tine does not obey timezones of incomming events. "
...
"Tine may use its default TZ to display the times in the global view, but it may not change the TZ itself. Furthermore, it would be nice, if Tine would actually include Europe/Moskau in the standardName/daylightName (Tine is using IANA names internally, so why not send them?). Above could also be, India/Mayotte... without a name it is hard to know..."

Steps to reproduce: Steps to reproduce this issue can be seen at jobisoft/TbSync#45 (comment)

Additional information: If you want to test with tbsync Plugin, always use the newest version at https://github.com/jobisoft/TbSync/releases. The author did a lot of changes which are not published at mozilla yet.

@Gloirin Gloirin self-assigned this Jun 9, 2018

@Gloirin

This comment has been minimized.

Show comment
Hide comment
@Gloirin

Gloirin Jun 11, 2018

Comment posted by estradis on 21 Mar 2018 20:41

Provided the wrong link. The "real" issue starts here
jobisoft/TbSync#45 (comment)

Gloirin commented Jun 11, 2018

Comment posted by estradis on 21 Mar 2018 20:41

Provided the wrong link. The "real" issue starts here
jobisoft/TbSync#45 (comment)

@Gloirin

This comment has been minimized.

Show comment
Hide comment
@Gloirin

Gloirin Jun 11, 2018

Comment posted by pschuele on 19 Apr 2018 14:26

hi estradis, thanks for the report. what is the advantage of using tbsync over the stock thunderbird/lightning sync?

I'm not sure about this:
"Also, Tine does not obey timezones of incomming events."

i'll pass this to Cornelius as TZ is his special area ;)

Gloirin commented Jun 11, 2018

Comment posted by pschuele on 19 Apr 2018 14:26

hi estradis, thanks for the report. what is the advantage of using tbsync over the stock thunderbird/lightning sync?

I'm not sure about this:
"Also, Tine does not obey timezones of incomming events."

i'll pass this to Cornelius as TZ is his special area ;)

@Gloirin

This comment has been minimized.

Show comment
Hide comment
@Gloirin

Gloirin Jun 11, 2018

Comment posted by jobisoft on 27 Apr 2018 07:54

Hi, I am the author of TbSync.

Lightning is using the CALDAV protocol to sync, TbSync is using EAS. For me, the advantage is the simplified setup process, you get task, events contacts in one go. Also I do not like the SOGo connector (which you need to get contacts via CARDDAV).

"Tine does not obey incoming timezones" means, that it will set incoming events (synced from client to Tine) always to the default timezone of the user (set up in the Tine 2.0 webinterface) and does not use the timezone of the event itself. This is not limited to TbSync but any EAS cleint I used to test Tine.

Gloirin commented Jun 11, 2018

Comment posted by jobisoft on 27 Apr 2018 07:54

Hi, I am the author of TbSync.

Lightning is using the CALDAV protocol to sync, TbSync is using EAS. For me, the advantage is the simplified setup process, you get task, events contacts in one go. Also I do not like the SOGo connector (which you need to get contacts via CARDDAV).

"Tine does not obey incoming timezones" means, that it will set incoming events (synced from client to Tine) always to the default timezone of the user (set up in the Tine 2.0 webinterface) and does not use the timezone of the event itself. This is not limited to TbSync but any EAS cleint I used to test Tine.

@Gloirin

This comment has been minimized.

Show comment
Hide comment
@Gloirin

Gloirin Jun 11, 2018

Comment posted by jobisoft on 27 Apr 2018 11:15

Let me give more details.

First of all, in the view layer, tine can do whatever it wants. If it wants to display an event, which is set to Moscow timezone in Berlin timezone, because that is the default timezone of the user, it can do that.

However, it should not CHANGE the timezone data field of the event from Moscow to Berlin. This is what tine is doing. If I sync an event with timezone set to Moscow from a client to Tine, and than look at another client, how this event comes back, it will have the timezone set to Berlin. I think, this is wrong.

The other issue is more within tine itself. If you create an event in Tine, it is using the default timezone, This way you can create multiple events with different timezone settings by changing the default timezone for each event. In the global view, all those events are shown in their LOCAL timezone, and not in a common timezone. Since the global view does not have any timezone identification, you cannot tell, when an event is actually occurring.

This image is an example: https://user-images.githubusercontent.com/5830621/37649582-822f2da6-2c32-11e8-9b61-ae4015a5c4e4.png

The two events have different timezones, which is fine. One at 9:00 Moskow time (5:00 UTC) and one at 11:00 Rome time (9:00 UTC). The global view is misleading. Both times should be converted to a common timezone (for example the default timezone) .

I think the title of this issue is not correct, both issues are issues with Tine 2.0

If you need further information, I will be happy to assist.

Gloirin commented Jun 11, 2018

Comment posted by jobisoft on 27 Apr 2018 11:15

Let me give more details.

First of all, in the view layer, tine can do whatever it wants. If it wants to display an event, which is set to Moscow timezone in Berlin timezone, because that is the default timezone of the user, it can do that.

However, it should not CHANGE the timezone data field of the event from Moscow to Berlin. This is what tine is doing. If I sync an event with timezone set to Moscow from a client to Tine, and than look at another client, how this event comes back, it will have the timezone set to Berlin. I think, this is wrong.

The other issue is more within tine itself. If you create an event in Tine, it is using the default timezone, This way you can create multiple events with different timezone settings by changing the default timezone for each event. In the global view, all those events are shown in their LOCAL timezone, and not in a common timezone. Since the global view does not have any timezone identification, you cannot tell, when an event is actually occurring.

This image is an example: https://user-images.githubusercontent.com/5830621/37649582-822f2da6-2c32-11e8-9b61-ae4015a5c4e4.png

The two events have different timezones, which is fine. One at 9:00 Moskow time (5:00 UTC) and one at 11:00 Rome time (9:00 UTC). The global view is misleading. Both times should be converted to a common timezone (for example the default timezone) .

I think the title of this issue is not correct, both issues are issues with Tine 2.0

If you need further information, I will be happy to assist.

@Gloirin

This comment has been minimized.

Show comment
Hide comment
@Gloirin

Gloirin Jun 11, 2018

Comment posted by pschuele on 3 May 2018 13:42

hi jobisoft, thanks for your input. i hope, that Cornelius finds some time to look at this, soon.

Gloirin commented Jun 11, 2018

Comment posted by pschuele on 3 May 2018 13:42

hi jobisoft, thanks for your input. i hope, that Cornelius finds some time to look at this, soon.

@Gloirin

This comment has been minimized.

Show comment
Hide comment
@Gloirin

Gloirin Jun 11, 2018

Comment posted by estradis on 6 May 2018 06:58

Hi John, as you're on this task now, I'm going to hold back. Is that ok for both sides?

Gloirin commented Jun 11, 2018

Comment posted by estradis on 6 May 2018 06:58

Hi John, as you're on this task now, I'm going to hold back. Is that ok for both sides?

@jobisoft

This comment has been minimized.

Show comment
Hide comment
@jobisoft

jobisoft Jun 20, 2018

Just posting here, to subscribe via github to this issue. Any news yet?

Just posting here, to subscribe via github to this issue. Any news yet?

@pschuele pschuele assigned corneliusweiss and unassigned Gloirin Jun 21, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment