Cargando…
Referencia en una nueva incidencia
Aún no existe contenido.
Eliminar la rama con el nombre '%!s(<nil>)'
Eliminar una rama es permanente. NO PUEDE deshacerse. ¿Continuar?
Eliminar una rama es permanente. NO PUEDE deshacerse. ¿Continuar?
Basic information
Description
Since two years I am having this issue and now I set down to track it.
The issue is that when I create event on the phone and sync via SyncEvolution the start time of the event is shifted.
This means the TimeZone from the payload is ignored and when converting to UTC, it does not convert the time to UTC but uses the values 1:1 adding Z for UTC at the end.
Steps to reproduce
alternatively
in this case it converts internally (line 201 in icalformat.cpp), where timezone is set per default to UTC.
DTSTART;TZID=Vienna:20201021T130000 turns into DTSTART:20201021T130000Z
Somehow I have the feeling that it is not working properly with the timezone.
Example
Payload as received and fed into KCal::ICalFormat in step 3
Payload after KCal::ICalFormat in step 4
Screenshots
It looks like I found the issue.
The local calendar is saved in UTC. The timezone in korganizer is set to something different. When I create local calendar with timezone=UTC it does not converted properly. If calender is opened with the local timezone it converts properly.
Testing
main.cpp
build
test
Hi Emanoil,
I think having the ability to use different time zones is a good feature, it may come handy for people traveling for example. Or for people dealing with other people in different tz.
Korganizer timezone settings is stored in korganizer resource file (korganizerrc), so you can get it from there.
Regarding 3., it is a good question. Here the first thing to understand is if the wrong sync is caused on the transfer from phone to PC or from PC to korganizer. When you create an event on your phone and sync to TDE, are the contents correct? IF so the problem would most likely be in how we import in KOrganizer. Instead if the contents was wrong, the problem could be on your phone or on the sync code.
Hi Michele,
thank you for your answer. My main problem is, that I do not see an easy way to read out this value from organizer programatically, or I couldn't find a way to do so. Do you have a hint where I can find something as an example?
I think at the moment this is most important as I want to send the patches to SyncEvolution - there will be new release coming soon.
I agree regarding 2 that it might be a good feature I just need a way to read it out from the plugin without too much effort.
Regarding 3 I already double checked. The problem is definitely somewhere in KCal code. I assume no one did catch it earlier as perhaps it was not a possible use case, or very specific one. I was going to see how the tests were build, but couldn't do it earlier today. Here are some findings
tdepim/libkcal/tests/data/Compat/MSExchange.ics
DTSTART;TZID="GMT -0800 (Standard) / GMT -0700 (Daylight)":20031110T100000
translates into
DTSTART:20031110T100000Z
while using Europe/Vienna translates into
DTSTART:20031110T090000Z
which is also not correct. IMO it should be DTSTART:20031110T180000Z
but in the testcases
tdepim/libkcal/tests/data/RecurrenceRule/UntilInUTC/Until_TestCase04.ics
tdepim/libkcal/tests/data/RecurrenceRule/UntilInUTC/Until_TestCase05.ics
tdepim/libkcal/tests/data/RecurrenceRule/UntilInUTC/Until_TestCase06.ics
DTSTART;TZID=America/Los_Angeles:19980101T090000
translates correctly to
DTSTART:19980101T170000Z
It has something to do with
TZID=Vienna
in not working case andTZID=Europe/Vienna
in the working case - I just tested now and usingTZID=Europe/Vienna
does the trick, however AFAIK both is legitim.So it looks like it doesn't matter if you initilize with UTC or local timezone, but how the TZID is formatted. The correct translation might be coincidence that I am importing into the same time zone.
I will test tomorrow.
regards
You can have a look here for how to access the timezone in the resource file.
From your description it seems the problem is related to using the correct time zone name, which may explain why tests never caught this before.
My be the standard changed, because TZID=Vienna is valid the same way as TZID=Europe/Vienna is.
below is what I receive from the phone and it validates perfectly well
https://icalendar.org/validator.html
Closing as it looks like TZID=Vienna is not a valid time zone. It should be TZID=Europe/Vienna
And that explains why we never had issues in the tests 😄
Glad to see we found where the issue is.
Yes, for the record I had to enable excessive debugging whe nrunning SyncEvolution.
Here is what is coming from the phone
As you can see TZID is correct - Europe/Vienna.
After translation in SyncEvolution "Europe/" is gone.
I was not confident what is the convention regarding timezone, the documentation is not very explicit, but it looks like there is nothing like Vienna and it should be Europe/Vienna. So when TZID=Vienna is received in TDE it defaults to UTC and as there is no offset indicator it shifts.
I am pretty sure that I did not observe this with N9 but it is obvious that it should be looked at in SyncEvolution.