Page MenuHomePhorge

Deduce a timezone for tasks due and start date
ClosedPublic

Authored by mollekopf on Nov 18 2020, 11:07 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 26 2024, 2:22 AM
Unknown Object (File)
Feb 23 2024, 9:04 PM
Unknown Object (File)
Feb 21 2024, 9:09 AM
Unknown Object (File)
Feb 16 2024, 9:09 PM
Unknown Object (File)
Feb 15 2024, 2:53 PM
Unknown Object (File)
Feb 14 2024, 10:16 PM
Unknown Object (File)
Feb 12 2024, 5:35 AM
Unknown Object (File)
Feb 9 2024, 7:23 PM
Subscribers

Details

Summary

Activesync doesn't know about timezones, but submits a utc and non-utc
value. We attempt to preserve this information by matching a timezone
with the same offset, so we can can replay a task with the same values
to another client.
If we don't do this the time will be stored as utc, and we will end up
replaying utcDueDate == dueDate, which will result in the client
displaying the task with an offset of the utc offset.
This solution will break down with clients in different timezones, but
that's just how it is unless we find a way to detect the clients
timezone.

Diff Detail

Repository
rS syncroton
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

mollekopf created this revision.
machniak subscribed.
machniak added inline comments.
lib/kolab_sync_data_tasks.php
172

Maybe this method should be moved to kolab_sync_timezone_converter.

176

Undefined variable $timezone. Also, please see kolab_sync_data::__construct() regarding $this->timezone. This is a user timezone (if set in Roundcube) or server timezone. We should prefer this timezone over any other matching the offset.

This revision now requires changes to proceed.Nov 19 2020, 8:18 AM

Moved the timezone guessing to kolab_sync_timezone_converter and take kolab_format::timezone into account.

Also now including the same logic for the start date.

This revision is now accepted and ready to land.Nov 19 2020, 12:49 PM
lib/kolab_sync_timezone_converter.php
107

Hmmm.. One more thing. Using 'now' everywhere is probably wrong. You're interested in an offset on the specified task start/due date not now. Right?

Take the timezone offset at the start date, not at the current date.

This revision was automatically updated to reflect the committed changes.