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.
<!--
This is a comment.
Please fill in the required fields below.
The comments provide instructions on how to do so.
Note: You do not need to remove comments.
-->
## Basic information
- TDE version: R14.1.x
- Distribution: Debian Buster
- Hardware: amd64
<!--
Use SL/* labels to set the severity level.
Please do not set a milestone.
-->
## 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
1. Use the input from the log below
2. create local calendar in UTC
```
KCal::CalendarLocal cal( TQString::fromLatin1( "UTC" ) );
```
3. use KCal::ICalFormat to convert the payload
```
format.fromString(&cal,data)
```
4. use KCal::ICalFormat to convert back to string and print
```
format.toString(&cal).utf8().data()
```
alternatively
1. Use the input from the log below
2. convert the payload
```
KCal::Incidence *e = format.fromString(data);
```
3. add to calendar
```
calendarPtr->addIncidence(e)
```
in this case it converts internally (line 201 in icalformat.cpp), where timezone is set per default to UTC.
```
CalendarLocal cal( mTimeZoneId );
fromString(&cal, text);
```
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
```
[INFO 00:00:06] calendar: adding "Tsst X5"
[DEBUG 00:00:06] calendar: Item to save: ( BEGIN:VCALENDAR
[DEBUG 00:00:06] calendar: VERSION:2.0
[DEBUG 00:00:06] calendar: PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.47//EN
[DEBUG 00:00:06] calendar: BEGIN:VTIMEZONE
[DEBUG 00:00:06] calendar: TZID:Vienna
[DEBUG 00:00:06] calendar: BEGIN:STANDARD
[DEBUG 00:00:06] calendar: DTSTART:19671029T030000
[DEBUG 00:00:06] calendar: RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU
[DEBUG 00:00:06] calendar: TZOFFSETFROM:+0200
[DEBUG 00:00:06] calendar: TZOFFSETTO:+0100
[DEBUG 00:00:06] calendar: TZNAME:CET
[DEBUG 00:00:06] calendar: END:STANDARD
[DEBUG 00:00:06] calendar: BEGIN:DAYLIGHT
[DEBUG 00:00:06] calendar: DTSTART:19870329T020000
[DEBUG 00:00:06] calendar: RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU
[DEBUG 00:00:06] calendar: TZOFFSETFROM:+0100
[DEBUG 00:00:06] calendar: TZOFFSETTO:+0200
[DEBUG 00:00:06] calendar: TZNAME:CEST
[DEBUG 00:00:06] calendar: END:DAYLIGHT
[DEBUG 00:00:06] calendar: END:VTIMEZONE
[DEBUG 00:00:06] calendar: BEGIN:VEVENT
[DEBUG 00:00:06] calendar: LAST-MODIFIED:20201017T220751Z
[DEBUG 00:00:06] calendar: DTSTAMP:20201017T220751Z
[DEBUG 00:00:06] calendar: CREATED:20201017T220751Z
[DEBUG 00:00:06] calendar: UID:01B6302A-0818-4571-835C-051FE69D0597
[DEBUG 00:00:06] calendar: TRANSP:OPAQUE
[DEBUG 00:00:06] calendar: SUMMARY:Tsst X5
[DEBUG 00:00:06] calendar: DTSTART;TZID=Vienna:20201021T130000
[DEBUG 00:00:06] calendar: DTEND;TZID=Vienna:20201021T140000
[DEBUG 00:00:06] calendar: END:VEVENT
[DEBUG 00:00:06] calendar: END:VCALENDAR
[DEBUG 00:00:06] calendar: )
```
Payload after KCal::ICalFormat in step 4
```
[DEBUG 00:00:06] calendar: Item to save from format: ( BEGIN:VCALENDAR
[DEBUG 00:00:06] calendar: PRODID:-//K Desktop Environment//NONSGML libkcal 3.5//EN
[DEBUG 00:00:06] calendar: VERSION:2.0
[DEBUG 00:00:06] calendar: BEGIN:VEVENT
[DEBUG 00:00:06] calendar: DTSTAMP:20201018T000807Z
[DEBUG 00:00:06] calendar: CREATED:20201017T220751Z
[DEBUG 00:00:06] calendar: UID:01B6302A-0818-4571-835C-051FE69D0597
[DEBUG 00:00:06] calendar: LAST-MODIFIED:20201017T220751Z
[DEBUG 00:00:06] calendar: SUMMARY:Tsst X5
[DEBUG 00:00:06] calendar: DTSTART:20201021T130000Z
[DEBUG 00:00:06] calendar: DTEND:20201021T140000Z
[DEBUG 00:00:06] calendar: TRANSP:OPAQUE
[DEBUG 00:00:06] calendar: END:VEVENT
[DEBUG 00:00:06] calendar: END:VCALENDAR
[DEBUG 00:00:06] calendar: )
[DEBUG 00:00:06] calendar: Item saved: ( 01B6302A-0818-4571-835C-051FE69D0597 )
```
## Screenshots
<!-- If it seems useful, please provide provide one or more 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.
question is how to get the timezone?
question is why is there a setting in korganizer to keep the timezone. Why not use /etc/timezone?
question is why all the tests we have do not catch this error?
Testing
main.cpp
/**
* test for issue with converting timezone
*
* use: ./testical test.cal default
* will load from /etc/timezone
*
* use: ./testical test.cal
* will use UTC
*
*/
#include <kdebug.h>
#include <tqfile.h>
#include <libkcal/icalformat.h>
#include <libkcal/calendarlocal.h>
int main(int argc, char** argv)
{
TQString filename;
TQString tz = "UTC";
if (argc > 1)
filename=argv[1];
else
filename="test.cal";
kdDebug(5800) << "Source: " << filename << endl;
TQFile file( filename );
if ( file.open( IO_ReadOnly ) ) {
TQTextStream stream( &file );
TQString line;
int i = 1;
while ( !stream.atEnd() ) {
line = stream.readLine(); // line of text excluding '\n'
printf( "%3d: %s\n", i++, line.local8Bit().data() );
}
file.close();
}
if (argv[2] == TQString("default") ) {
TQFile filetz( "/etc/timezone" );
if ( filetz.open( IO_ReadOnly ) ) {
TQTextStream stream( &filetz );
tz = stream.readLine();
filetz.close();
}
}
KCal::CalendarLocal cal( tz );
KCal::ICalFormat format;
format.load(&cal,filename);
TQString data1 = format.toString( &cal );
kdDebug(5800) << "Timezone: " << cal.timeZoneId()<< endl;
printf( "===================\n" );
printf( "%s\n", filename.local8Bit().data() );
printf( "%s\n", cal.timeZoneId().local8Bit().data() );
printf( "===================\n" );
printf( "%s\n", data1.local8Bit().data() );
return 0;
}
find <PATH TO GIT REPO>/tde/1_git/tde/main/tdepim/libkcal/tests/data/ -type f -name '*.ics' | while read line; do ./testical $line default; done > /tmp/test.1
find <PATH TO GIT REPO>/tde/1_git/tde/main/tdepim/libkcal/tests/data/ -type f -name '*.ics' | while read line; do ./testical $line; done > /tmp/test.2
diff -ub /tmp/test.1 /tmp/test.2 | more
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.
1. question is how to get the timezone?
2. question is why is there a setting in korganizer to keep the timezone. Why not use /etc/timezone?
3. question is why all the tests we have do not catch this error?
# Testing
## main.cpp
```
/**
* test for issue with converting timezone
*
* use: ./testical test.cal default
* will load from /etc/timezone
*
* use: ./testical test.cal
* will use UTC
*
*/
#include <kdebug.h>
#include <tqfile.h>
#include <libkcal/icalformat.h>
#include <libkcal/calendarlocal.h>
int main(int argc, char** argv)
{
TQString filename;
TQString tz = "UTC";
if (argc > 1)
filename=argv[1];
else
filename="test.cal";
kdDebug(5800) << "Source: " << filename << endl;
TQFile file( filename );
if ( file.open( IO_ReadOnly ) ) {
TQTextStream stream( &file );
TQString line;
int i = 1;
while ( !stream.atEnd() ) {
line = stream.readLine(); // line of text excluding '\n'
printf( "%3d: %s\n", i++, line.local8Bit().data() );
}
file.close();
}
if (argv[2] == TQString("default") ) {
TQFile filetz( "/etc/timezone" );
if ( filetz.open( IO_ReadOnly ) ) {
TQTextStream stream( &filetz );
tz = stream.readLine();
filetz.close();
}
}
KCal::CalendarLocal cal( tz );
KCal::ICalFormat format;
format.load(&cal,filename);
TQString data1 = format.toString( &cal );
kdDebug(5800) << "Timezone: " << cal.timeZoneId()<< endl;
printf( "===================\n" );
printf( "%s\n", filename.local8Bit().data() );
printf( "%s\n", cal.timeZoneId().local8Bit().data() );
printf( "===================\n" );
printf( "%s\n", data1.local8Bit().data() );
return 0;
}
```
## build
```
/usr/bin/g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time \
-D_FORTIFY_SOURCE=2 -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT \
-DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/usr/include/tqt3 \
-I/opt/trinity/include/ -I/usr/include/tqt -I -DQT_NO_ASCII_CAST \
-DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT \
-Wl,-z,relro main.cpp -o testical \
-L/opt/trinity/lib -ltqt -ltdepim -ltqt-mt -ltdecore -lkcal
```
## test
```
find <PATH TO GIT REPO>/tde/1_git/tde/main/tdepim/libkcal/tests/data/ -type f -name '*.ics' | while read line; do ./testical $line default; done > /tmp/test.1
find <PATH TO GIT REPO>/tde/1_git/tde/main/tdepim/libkcal/tests/data/ -type f -name '*.ics' | while read line; do ./testical $line; done > /tmp/test.2
diff -ub /tmp/test.1 /tmp/test.2 | more
```
question is why is there a setting in korganizer to keep the timezone. Why not use /etc/timezone?
question is why all the tests we have do not catch this error?
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.
> 1. question is how to get the timezone?
> 2. question is why is there a setting in korganizer to keep the timezone. Why not use /etc/timezone?
> 3. question is why all the tests we have do not catch this error?
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.<br/>
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
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 and TZID=Europe/Vienna in the working case - I just tested now and using TZID=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
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 and `TZID=Europe/Vienna` in the working case - I just tested now and using `TZID=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.
You can have a look [here](https://mirror.git.trinitydesktop.org/gitea/TDE/tdepim/src/branch/master/korganizer/korgac/testalarmdlg.cpp#L46) 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
```
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.47//EN
BEGIN:VTIMEZONE
TZID:Vienna
BEGIN:STANDARD
DTSTART:19671029T030000
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19870329T020000
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
LAST-MODIFIED:20201017T220751Z
DTSTAMP:20201017T220751Z
CREATED:20201017T220751Z
UID:01B6302A-0818-4571-835C-051FE69D0597
TRANSP:OPAQUE
SUMMARY:Tsst X5
DTSTART;TZID=Vienna:20201021T130000
DTEND;TZID=Vienna:20201021T140000
END:VEVENT
END:VCALENDAR
```
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.
Yes, for the record I had to enable excessive debugging whe nrunning SyncEvolution.
Here is what is coming from the phone
```
BEGIN:VCALENDAR
PRODID:-//K Desktop Environment//NONSGML libkcal 4.3//EN
VERSION:2.0
X-KDE-ICAL-IMPLEMENTATION-VERSION:1.0
BEGIN:VTIMEZONE
TZID:Europe/Vienna
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+010521
TZOFFSETTO:+0100
DTSTART:20380119T031408
RDATE:20380119T031408
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19810329T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:DAYLIGHT
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19160501T220000
RDATE:19160501T220000
RDATE:19170416T010000
RDATE:19180415T010000
RDATE:19200405T010000
RDATE:19400401T010000
RDATE:19430329T010000
RDATE:19440403T010000
RDATE:19450402T010000
RDATE:19460414T010000
RDATE:19470406T010000
RDATE:19480418T010000
RDATE:19800405T230000
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19810927T030000
RRULE:FREQ=YEARLY;COUNT=15;BYDAY=-1SU;BYMONTH=9
END:STANDARD
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19961027T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19161001T230000
RDATE:19161001T230000
RDATE:19170917T020000
RDATE:19180916T020000
RDATE:19200913T020000
RDATE:19421102T020000
RDATE:19431004T020000
RDATE:19441002T020000
RDATE:19450412T020000
RDATE:19461006T020000
RDATE:19471005T020000
RDATE:19481003T020000
RDATE:19800927T220000
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20201026T195124Z
CREATED:20201026T195124Z
UID:C926ABD3-7A76-4E1D-ACD3-AEEEAE2C1384
LAST-MODIFIED:20201026T195124Z
SUMMARY:Tsst 3
DTSTART;TZID=Europe/Vienna:20201027T210000
DTEND;TZID=Europe/Vienna:20201027T220000
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
```
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.
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.