TDE
/
tdepim
6
0
Forkuj 1
Kod Zgłoszenia 23 Oczekujące zmiany 4 Wydania Wiki Aktywność
Etykiety Kamienie milowe
Nowe zgłoszenie

kcal format breaking timezone #47

Zamknięty
otworzone 4 lat temu przez deloptes · 8 komentarzy
deloptes skomentował(-a) 4 lat temu
Współpracownik

Basic information

  • TDE version: R14.1.x
  • Distribution: Debian Buster
  • Hardware: amd64

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" ) );
  1. use KCal::ICalFormat to convert the payload
format.fromString(&cal,data)
  1. 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);
  1. 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

<!-- 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. -->
deloptes skomentował(-a) 4 lat temu
Autor
Współpracownik

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
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 ```
MicheleC skomentował(-a) 4 lat temu
Właściciel
  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.

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.
deloptes skomentował(-a) 4 lat temu
Autor
Współpracownik

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

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
MicheleC skomentował(-a) 4 lat temu
Właściciel

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.
deloptes skomentował(-a) 4 lat temu
Autor
Współpracownik

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
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 ```
deloptes skomentował(-a) 4 lat temu
Autor
Współpracownik

Closing as it looks like TZID=Vienna is not a valid time zone. It should be TZID=Europe/Vienna

Closing as it looks like TZID=Vienna is not a valid time zone. It should be TZID=Europe/Vienna
deloptes zamknął(-ęła) to zgłoszenie 4 lat temu
MicheleC skomentował(-a) 4 lat temu
Właściciel

And that explains why we never had issues in the tests 😄

Glad to see we found where the issue is.

And that explains why we never had issues in the tests :smile: Glad to see we found where the issue is.
deloptes skomentował(-a) 4 lat temu
Autor
Współpracownik

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.

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.
👍 1
SlavekB dodaje to do kamienia milowego R14.1.0 release 3 lat temu
SlavekB dodano ST/notourproblem etykietę 3 lat temu
Zaloguj się, aby dołączyć do tej rozmowy.
Nie określono gałęzi/etykiety
Gałęzie Tagi
issue/119/filename-escape
r14.1.x
master
bug/94/open-html
feat/korganizer
feat/karm-busyCntr-itemReset
r14.0.x
v3.5.13-sru
Etykiety
Zastosuj etykiety
Wyczyść etykiety
GE/need-info
General - need additional info from contributor PR/keep-branch
Pull request - do not delete branch after merging PR/not-ok
Pull request - need fixing PR/rfc
Pull request - request for comments PR/update-trans
Pull request - update to translation files needed PR/wip
Pull request - work in progress RS/R14.0.x
Related to R14.0.x series RS/R14.1.x
Related to R14.1.x series SL/critical
Severity level - critical SL/major
Severity level - major SL/minor
Severity level - minor SL/normal
Severity level - normal SL/regression
Severity level - regression from previous version SL/trivial
Severity level - trivial SL/wishlist
Severity level - wishlist request ST/duplicate
Status - duplicate of another issue ST/invalid
Status - invalid report ST/notourproblem
Status - not our problem ST/rejected
Status - rejected ST/wontfix
Status - won't fix ST/worksforme
Status - works for me, unable to reproduce
Brak etykiety GE/need-info PR/keep-branch PR/not-ok PR/rfc PR/update-trans PR/wip RS/R14.0.x RS/R14.1.x SL/critical SL/major SL/minor SL/normal SL/regression SL/trivial SL/wishlist ST/duplicate ST/invalid ST/notourproblem ST/rejected ST/wontfix ST/worksforme
Kamień milowy
Ustaw kamień milowy
Wyczyść kamień milowy
Brak elementów
Brak kamienia milowego
R14.1.0 release
Przypisani
Przypisz użytkowników
Usuń przypisanych
Brak przypisanych
Uczestnicy 2
Powiadomienia
Termin realizacji

Brak ustawionego terminu realizacji.

Zależności

No dependencies set.

Reference: TDE/tdepim#47
Napisz Podgląd
Ładowanie…
Anuluj
Zapisz
Nie ma jeszcze treści.
Usuń gałąź '%!s(<nil>)'

Usunięcie gałęzi jest trwałe i NIE MOŻE zostać cofnięte. Kontynuować?

Nie
Tak