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.
Details
Details
- Reviewers
machniak - Commits
- rS494693bb629e: Deduce a timezone for tasks due and start date
Diff Detail
Diff Detail
- Repository
- rS syncroton
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
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. |
Comment Actions
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.
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? |