12:38 p.m.
http://bugs.meego.com/show_bug.cgi?id=6680
Summary: Explicit TZID is ignored when importing events.
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: All
Architecture: ---
Status: NEW
Severity: normal
Priority: Undecided
Component: Maemo 5
AssignedTo: ovek(a)debian.org
ReportedBy: monkeyiq(a)users.sourceforge.net
QAContact: jingke.zhang(a)intel.com
CC: syncevolution-bugs(a)meego.bugs,
syncevolution-maemo5-bugs(a)meego.bugs
Estimated Hours: 0.0
BUILD IMAGE(X.X.XX.X.XXXXXXXX.X - (e.g.:
meego-netbook-ia32-1.0.90.0.20100831.1)): PR1.2
HARDWARE MODEL (on what HW this bug is uncovered): n900
BUG DETAILED DESCRIPTIONS
===========================================================
EXACT STEPS LEADING TO PROBLEM:
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
===========================================================
1. Have multiple clients using a syncml server and syncevolution to sync
calendar data
2. Setup n900 and syncevolution --sync refresh-from-server xxx calendar
3. See events which have a timezone have the TZ ignored and become UTC without
any offset applied (ie, 8:00 localtime in GMT+10 becomes 18:00 in GMT+10).
4.
5.
EXPECTED OUTCOME:
===================
The timezone from the TZID, TZNAME, DTSTART should be preserved or when
converting to UTC it should be taken into account. I'm not sure what is
actually dropping the info, it seems that syncevolution knows about the
timezones from the entries (looking at syncevolution-log.html)
ACTUAL OUTCOME:
===================
One the desktop a specific calendar.after
BEGIN:VTIMEZONE
TZID:/freeassociation.sourceforge.net/Tzfile/Australia/Brisbane
X-LIC-LOCATION:Australia/Brisbane
BEGIN:STANDARD
TZNAME:EST
DTSTART:19700301T020000
TZOFFSETFROM:+1000
TZOFFSETTO:+1000
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
...
UID:20100708T090537Z-2014-1006-1-2@myserverer
DTSTAMP:20100708T090537Z
DTSTART;TZID=/freeassociation.sourceforge.net/Tzfile/Australia/Brisbane:
20100911T163000
DTEND;TZID=/freeassociation.sourceforge.net/Tzfile/Australia/Brisbane:
20100911T210000
On the n900 calendar.after using --sync refresh-from-server for the same vevent
file which has no BEGIN:VTIMEZONE.
DTSTART:20100911T163000Z
DTEND:20100911T210000Z
It appears that the DTSTART is preserved as Zulu time without any consideration
of the TZID. This effectively moves entries +10hrs in the calendar on the
device.
USER IMPACT:
===================
Calendar sync is not useful without timezone preservation.
REPRODUCIBILITY:
(always, less than 1/10, 5/10, 9/10)
=====================================
always
EXTRA SOFTWARE INSTALLED:
============================
OTHER COMMENTS:
===================
I've tried setting /etc/timezone etc, but it appears that the actual TZ
information is in the data from the syncml server.
From one of the syncevolution-log.html files, it seems that
syncevolution knows
about the timezone:
...
- 18 : timestamp DTSTART [ 0, 0, 0] : 2010-09-11T16:30:00
(imported TZ: /freeassociation.sourceforge.net/Tzfile/Australia/Brisbane)
Is there a way to force syncevolution to convert to UTC and drop the timezone
so that the n900 doesn't get confused?
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
6:44 p.m.
New subject: [Bug 6680] Explicit TZID is ignored when importing events.
http://bugs.meego.com/show_bug.cgi?id=6680
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |patrick.ohly(a)intel.com
--- Comment #1 from pohly <patrick.ohly(a)intel.com> 2010-09-14 01:44:56 PDT ---
(In reply to comment #0)
From one of the syncevolution-log.html files, it seems that
syncevolution knows
about the timezone:
...
- 18 : timestamp DTSTART [ 0, 0, 0] : 2010-09-11T16:30:00
(imported TZ: /freeassociation.sourceforge.net/Tzfile/Australia/Brisbane)
Is there a way to force syncevolution to convert to UTC and drop the timezone
so that the n900 doesn't get confused?
This can be done with Synthesis scripts. But before going there it would be
better to understand which component drops the time zone.
From what you described, it seems that SyncEvolution core and
Synthesis are
doing the right thing. You can verify this further by running with
logLevel =
4, which will include more extensive logging of data conversion. The most
relevant part is the "created" VCALENDAR item right before it is passed to the
Maemo calendar backend.
From there I have to defer to Ove - he wrote that code and perhaps
already
knows about Maemo calendar storage issues.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
8:26 p.m.
New subject: [Bug 6680] Explicit TZID is ignored when importing events.
http://bugs.meego.com/show_bug.cgi?id=6680
--- Comment #2 from monkeyiq <monkeyiq(a)users.sourceforge.net> 2010-09-14 03:26:15
PDT ---
OK, for loglevel 4 it seems that things do indeed percolate right down to the
bottom level. This is using a source type = maemo-events I've tried with a few
additional :restrictions there to no avail.
I also tried 1.0 and syncevolution_0.9.2-4_armel.deb against a local funambol
server but keep getting the same issue on the n900.
<span class="outgoing">Generated: </span></li>
<span class="outgoing"><pre>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.8//EN
BEGIN:VTIMEZONE
TZID:/freeassociation.sourceforge.net/Tzfile/Australia/Brisbane
BEGIN:STANDARD
DTSTART:19670101T000000
TZOFFSETFROM:+1000
TZOFFSETTO:+1000
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CLASS:PUBLIC
SUMMARY:....
DESCRIPTION:...
DTSTART;TZID=/freeassociation.sourceforge.net/Tzfile/Australia/Brisbane:201
00911T163000
DTEND;TZID=/freeassociation.sourceforge.net/Tzfile/Australia/Brisbane:20100
911T210000
END:VEVENT
END:VCALENDAR
</pre></span>
...
[2010-09-14 04:53:06.273]</i> InsertItemAsKey res=0</li>
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
9:02 p.m.
New subject: [Bug 6680] Explicit TZID is ignored when importing events.
http://bugs.meego.com/show_bug.cgi?id=6680
--- Comment #3 from ovek <ovek(a)debian.org> 2010-09-14 04:02:41 PDT ---
I might have to suggest forcing vcalendar format...
Nokia's calendar-backend wants to convert the vcal to something it can store in
is internal SQLite database. I've taken a quick look at the sources for their
parser, and from what I can tell, it might not handle TZID fields of this type,
only stuff like "TZID=Australia/Brisbane" (the ical date import code should
have used icaltimezone_get_builtin_timezone_from_tzid() instead of
icaltimezone_get_builtin_timezone() to parse this property). If so, perhaps a
bug for that should be filed on bugs.maemo.org.
As a fallback, it will of course try the VTIMEZONE information, where the
parser will, if all else fails, try to infer the timezone from the GMT offset
and daylight savings information. However, this also fails, because for some
reason, it only looks at TZOFFSETTO if there's also a RRULE. Go figure. Hence,
timezones without daylight savings rules will be treated as GMT. Another
calendar bug, I suppose...
Probably nothing syncevolution can do about that other than perhaps use
vcalendar as much as possible, until someone fixes Nokia's stuff.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
9:06 p.m.
New subject: [Bug 6680] Explicit TZID is ignored when importing events.
http://bugs.meego.com/show_bug.cgi?id=6680
--- Comment #4 from ovek <ovek(a)debian.org> 2010-09-14 04:06:45 PDT ---
Or perhaps force UTC like suggested, I suppose, but since the calendar database
does store the timezone of the original entry (or is at least supposed to),
that would perhaps lose a bit of information...
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
9:25 p.m.
New subject: [Bug 6680] Explicit TZID is ignored when importing events.
http://bugs.meego.com/show_bug.cgi?id=6680
--- Comment #5 from pohly <patrick.ohly(a)intel.com> 2010-09-14 04:25:47 PDT ---
(In reply to comment #4)
Or perhaps force UTC like suggested, I suppose, but since the
calendar database
does store the timezone of the original entry (or is at least supposed to),
that would perhaps lose a bit of information...
Agreed, storing in UTC looses relevant information. For example, recurring
meetings crossing the daylight saving transitions won't work correctly.
If someone is interested in going down that route, then I can provide some
pointers. I don't have time for a fully working solution.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
9:42 a.m.
New subject: [Bug 6680] Explicit TZID is ignored when importing events.
http://bugs.meego.com/show_bug.cgi?id=6680
--- Comment #6 from monkeyiq <monkeyiq(a)users.sourceforge.net> 2010-09-14 16:42:24
PDT ---
OK, changing sources/calendar/config.ini
# has tzid bug on import to nokia
#type = maemo-events:text/calendar
# works ok
type = maemo-events:text/x-vcalendar
puts the event where it should be time wise on the device.
It seems from calendar.after that the nokia import is just storing it in Z time
and recording GMT+10 as the TZ for vcalendar.
BEGIN:VCALENDAR
VERSION:1.0
TZ:+10
DAYLIGHT:FALSE
PRODID://Nokia Corporation//Maemo5 Calendar PR1.2//EN
BEGIN:VEVENT
SUMMARY;...
DESCRIPTION;...
DTSTART:20100911T063000Z
DTEND:20100911T110000Z
ATTACH:
SEQUENCE:0
CLASS:PUBLIC
LAST-MODIFIED:20100914T225119Z
DCREATED:20100914T225119Z
END:VEVENT
END:VCALENDAR
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
9:53 a.m.
New subject: [Bug 6680] Explicit TZID is ignored when importing events.
http://bugs.meego.com/show_bug.cgi?id=6680
--- Comment #7 from monkeyiq <monkeyiq(a)users.sourceforge.net> 2010-09-14 16:53:17
PDT ---
Is it somewhat easy to have syncevo convert
TZID:/freeassociation.sourceforge.net/Tzfile/Australia/Brisbane
to the possibly nokia understood:
TZID=Australia/Brisbane
I imagine in a generic way sub sort of s/a/b/ table would help folks or distros
work around these issues. Or perhaps just pipe to to a script of the user's
choosing prior to import. I'll dig into sync evo to see if there is such stuff
already, sorry for asking up front... Such a thing might also be useful for
supporting other libraries and platforms which also have a limited
understanding of timezones.
Otherwise, trying to convert
TZID:/freeassociation.sourceforge.net/Tzfile/Australia/Brisbane
to the respective TZ offset and daylight savings time block would probably
require a bit more hacking.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
3:27 p.m.
New subject: [Bug 6680] Explicit TZID is ignored when importing events.
http://bugs.meego.com/show_bug.cgi?id=6680
--- Comment #8 from ovek <ovek(a)debian.org> 2010-09-14 22:27:27 PDT ---
Hmm. Perhaps wouldn't be too hard to just add a very simple search&replace to
the insert/update command in the syncevolution backend for Maemo (hopefully
won't also have to do the reverse substitution for the read command), but I
wonder if there a risk of replacing something we don't want to replace that
way?
Other types of ical imports with such tzids would still fail, but I suppose
most people won't generally be using any other types of ical imports to the
N900 calendar... I don't even see an import option in the menu, guess they
probably only did it for use with PC Suite (and perhaps Backup/Restore).
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
12:46 a.m.
New subject: [Bug 6680] Explicit TZID is ignored when importing events.
http://bugs.meego.com/show_bug.cgi?id=6680
--- Comment #9 from pohly <patrick.ohly(a)intel.com> 2010-09-15 07:46:50 PDT ---
(In reply to comment #7)
Is it somewhat easy to have syncevo convert
TZID:/freeassociation.sourceforge.net/Tzfile/Australia/Brisbane
to the possibly nokia understood:
TZID=Australia/Brisbane
I imagine in a generic way sub sort of s/a/b/ table would help folks or distros
work around these issues. Or perhaps just pipe to to a script of the user's
choosing prior to import. I'll dig into sync evo to see if there is such stuff
already, sorry for asking up front... Such a thing might also be useful for
supporting other libraries and platforms which also have a limited
understanding of timezones.
Such platforms are just plain broken. The TZID is meant to be an opaque string.
Only supporting TZIDs that are already stored locally and match against those
based on the TZID string is always going to fail for some valid items.
Having said that, perhaps there is an easy way to work around this:
libsynthesis extracts a full copy of all system time zones via libical. The log
message "imported TZ:
/freeassociation.sourceforge.net/Tzfile/Australia/Brisbane" refers to that.
The code could be changed so that it strips the prefix before adding a time
zone definition. Then the Maemo calendar should be passed the simplified TZID
that it expects. Other backends already need to work with arbitrary TZIDs and
should work without the /freeassociation.sourceforge.net/Tzfile/ prefix.
That code is in
libsynthesis/src/platform_adapters/linux/platform_timezones.cpp, if someone
wants to have a look.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
12:01 p.m.
New subject: [Bug 6680] Explicit TZID is ignored when importing events.
http://bugs.meego.com/show_bug.cgi?id=6680
--- Comment #10 from monkeyiq <monkeyiq(a)users.sourceforge.net> 2010-09-16 19:01:01
PDT ---
Nokia's calendar-backend has mentioned in comment #3. Any tips as to what
bugzilla etc to report that in? I'd like to move/link this across so it is at
least known in the right place at Nokia.
Maybe then we can move to waiting for upstream as the bug status.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
9:23 p.m.
New subject: [MeeGo Projects - Bug 6680] N900 calendar: explicit TZID is ignored when importing events.
http://bugs.meego.com/show_bug.cgi?id=6680
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
AssignedTo|ovek(a)debian.org |patrick.ohly(a)intel.com
Summary|Explicit TZID is ignored |N900 calendar: explicit
|when importing events. |TZID is ignored when
| |importing events.
--- Comment #11 from pohly <patrick.ohly(a)intel.com> 2010-12-15 02:23:18 PST ---
Let me see whether I can change the TZID in SyncEvolution 1.1.1.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
6:55 p.m.
New subject: [MeeGo Projects - Bug 6680] N900 calendar: explicit TZID is ignored when importing events.
http://bugs.meego.com/show_bug.cgi?id=6680
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|patrick.ohly(a)intel.com |ovek(a)debian.org
--- Comment #12 from pohly <patrick.ohly(a)intel.com> 2010-12-15 23:55:31 PST ---
(In reply to comment #11)
Let me see whether I can change the TZID in SyncEvolution 1.1.1.
I've changed in the libsynthesis which will be used in 1.1.1 and so far see no
drawbacks. Ove, do you see a chance to update to that as the backend of your
UI?
commit 3d76d2399ba9312290375e8f97755b8db87628bf
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Wed Dec 15 15:23:41 2010 +0100
Linux time zones: use TZID=<location> instead of
TZID=/softwarestudio.org/Tzfile/<location>
The shorter TZIDs will be included in iCalendar 2.0 data exported
by libsyntesis.
This change is motivated primarily by the observation that the N900
calendar storage can handle TZID=<location>, but not
TZID=/softwarestudio.org/Tzfile/<location> (BMC #6680). It seems to do
a literal comparison against its built-in time zone definitions and
cannot handle definitions which have no match.
The mKCal storage in MeeGo (N900 successor) can handle custom
definitions, but also benefits from the change: TZID=<location> is
mapped to the internal definitions, which are more complete (include
transition dates for multiple years).
A secondary benefit is slightly shorter item data in SyncML messages.
The risk is that peers which depended on the
TZID=/softwarestudio.org/Tzfile/<location> format break (fail to deal
with definition) or become less efficient (have to fall back to custom
time zone handling).
There are no known peers with such a limitation. Untested peers which
break completely were arguably already broken without this change. In
practice, testing shows that at least the following peers are not
affected at all:
* Evolution calendar storage: my e_cal_match_location() is able to
match TZID=<location> to the system time zones and thus Evolution
continues to use the same time zone definitions as before.
* Funambol itself already uses the shorter format and can receive it
just fine.
* An older SyncEvolution server with the unmodified time zone import
code also maps to the imported definitions.
--
Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
4294
days inactive
4387
days old
syncevolution-issues@syncevolution.org
12 comments
1 participants
participants (1)
-
bugzilla＠meego.com