---- Reported by monkeyiq@users.sourceforge.net 2010-09-13 19:38:50 +0000 ----

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?



---- Additional Comments From patrick.ohly@gmx.de 2010-09-14 01:44:56 +0000 ----

(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.



---- Additional Comments From monkeyiq@users.sourceforge.net 2010-09-14 03:26:15 +0000 ----

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>&nbsp;InsertItemAsKey res=0</li>



---- Additional Comments From ovek@debian.org 2010-09-14 04:02:41 +0000 ----

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.



---- Additional Comments From ovek@debian.org 2010-09-14 04:06:45 +0000 ----

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...



---- Additional Comments From patrick.ohly@gmx.de 2010-09-14 04:25:47 +0000 ----

(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.



---- Additional Comments From monkeyiq@users.sourceforge.net 2010-09-14 16:42:24 +0000 ----

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



---- Additional Comments From monkeyiq@users.sourceforge.net 2010-09-14 16:53:17 +0000 ----

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.



---- Additional Comments From ovek@debian.org 2010-09-14 22:27:27 +0000 ----

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).



---- Additional Comments From patrick.ohly@gmx.de 2010-09-15 07:46:50 +0000 ----

(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.



---- Additional Comments From monkeyiq@users.sourceforge.net 2010-09-16 19:01:01 +0000 ----

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.



---- Additional Comments From patrick.ohly@gmx.de 2010-12-15 02:23:18 +0000 ----

Let me see whether I can change the TZID in SyncEvolution 1.1.1.



---- Additional Comments From patrick.ohly@gmx.de 2010-12-15 23:55:31 +0000 ----

(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@gmx.de>
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.



---- Additional Comments From ovek@debian.org 2011-02-04 16:15:15 +0000 ----

I've built syncevolution 1.1.1, you should be able to download either the official build at http://maemo.org/packages/view/syncevolution/ (once it's installed) or my own build at http://people.debian.org/~ovek/maemo/

Please check if it solves the problem or not.



--- Bug imported by patrick.ohly@gmx.de 2012-08-19 20:56 UTC  ---

This bug was previously known as _bug_ 6680 at https://bugs.meego.com/show_bug.cgi?id=6680

Unknown platform unknown. Setting to default platform "".
Unknown operating system unknown. Setting to default OS "".