Wednesday, December 16, 2020, 6:48:59 PM, you wrote:
> Help Please! I am using Evolution to schedule calendar events.
> Fedora 33
> Evolution 3.38.2 (3.38.2-1.fc33)
> DavMail
> EWS
> When they are received by a person using Outlook, The time is being shifted
> off by an hour. Goggling shows this to be related to the Timezone in the
> invite. Checking the timezones. Server and client Time zones seem Ok/
> Server and both sending receiving clients are all in US Eastern Time zone.
> The raw message sent has tags that show Tags all have 3D after all the rqual
> signs. The TZID tag shows correctly
> TZID:America/New_York
> But later on I see the reference
> TZID=3DAmerica/New_York:20201216T100000
> Am I missing something in the translation as to why all equals are followed
> with 3D? Is this what is causing the Calendar invites to be misinterpreted by
> Outlook clients? How is this corrected?
> Raw message (redacted) sent is below.
> Message-ID: <c3ace07fe3650ffca517f6e59cd21a89451c4610.ca...@xyleminc.com>
> Subject: Review Public IP in CoH
> From: {Redacted}
> To: {Redacted}
> Date: Tue, 15 Dec 2020 16:48:24 -0500
> Organization: {Redacted}
> Content-Type: text/calendar; name="calendar.ics"; charset="utf-8";
> method=REQUEST
> User-Agent: Evolution 3.38.2 (3.38.2-1.fc33)
> Content-Transfer-Encoding: quoted-printable
> X-Evolution-Identity: 6608fad2747da18240548b4800132bce0b465b1a
> X-Evolution-Fcc: folder://eb90bc54a7fa5b2802fe7855926e76e9d34af2ea/Sent
> X-Evolution-Transport: 771a9683fea71ec84d5f113ae3e45a0b64f41267
> X-Evolution-Source:
> Keywords: $has_cal
> MIME-Version: 1.0
> BEGIN:VCALENDAR
> CALSCALE:GREGORIAN
> PRODID:-//Ximian//NONSGML Evolution Calendar//EN
> VERSION:2.0
> METHOD:REQUEST
> BEGIN:VTIMEZONE
> TZID:America/New_York
> X-LIC-LOCATION:America/New_York
> BEGIN:DAYLIGHT
> TZNAME:EDT
> DTSTART:19180329T020000
> TZOFFSETFROM:-0500
> TZOFFSETTO:-0400
> RRULE:FREQ=3DYEARLY;UNTIL=3D19200328T070000Z;BYDAY=3D-1SU;BYMONTH=3D3
> END:DAYLIGHT
> BEGIN:STANDARD
> TZNAME:EST
> DTSTART:19181025T020000
> TZOFFSETFROM:-0400
> TZOFFSETTO:-0500
> RRULE:FREQ=3DYEARLY;UNTIL=3D19201031T060000Z;BYDAY=3D-1SU;BYMONTH=3D10
> END:STANDARD
> BEGIN:DAYLIGHT
> TZNAME:EDT
> DTSTART:19210426T020000
> TZOFFSETFROM:-0500
> TZOFFSETTO:-0400
> RRULE:FREQ=3DYEARLY;UNTIL=3D19410427T070000Z;BYDAY=3D-1SU;BYMONTH=3D4
> END:DAYLIGHT
> BEGIN:STANDARD
> TZNAME:EST
> DTSTART:19210927T020000
> TZOFFSETFROM:-0400
> TZOFFSETTO:-0500
> RRULE:FREQ=3DYEARLY;UNTIL=3D19540926T060000Z;BYDAY=3D-1SU;BYMONTH=3D9
> END:STANDARD
> BEGIN:DAYLIGHT
> TZNAME:EWT
> DTSTART:19420210T020000
> TZOFFSETFROM:-0500
> TZOFFSETTO:-0400
> RRULE:FREQ=3DYEARLY;UNTIL=3D19420209T060000Z;BYDAY=3D2MO;BYMONTH=3D2
> END:DAYLIGHT
> BEGIN:DAYLIGHT
> TZNAME:EPT
> DTSTART:19450811T190000
> TZOFFSETFROM:-0400
> TZOFFSETTO:-0400
> RRULE:FREQ=3DYEARLY;UNTIL=3D19450815T000000Z;BYDAY=3D2TU;BYMONTH=3D8
> END:DAYLIGHT
> BEGIN:DAYLIGHT
> TZNAME:EDT
> DTSTART:19460426T020000
> TZOFFSETFROM:-0500
> TZOFFSETTO:-0400
> RRULE:FREQ=3DYEARLY;UNTIL=3D19730429T070000Z;BYDAY=3D-1SU;BYMONTH=3D4
> END:DAYLIGHT
> BEGIN:STANDARD
> TZNAME:EST
> DTSTART:19551025T020000
> TZOFFSETFROM:-0400
> TZOFFSETTO:-0500
> RRULE:FREQ=3DYEARLY;UNTIL=3D20061029T060000Z;BYDAY=3D-1SU;BYMONTH=3D10
> END:STANDARD
> BEGIN:DAYLIGHT
> TZNAME:EDT
> DTSTART:19740105T020000
> TZOFFSETFROM:-0500
> TZOFFSETTO:-0400
> RRULE:FREQ=3DYEARLY;UNTIL=3D19740106T070000Z;BYDAY=3D1SU;BYMONTH=3D1
> END:DAYLIGHT
> BEGIN:DAYLIGHT
> TZNAME:EDT
> DTSTART:19750223T020000
> TZOFFSETFROM:-0500
> TZOFFSETTO:-0400
> RRULE:FREQ=3DYEARLY;UNTIL=3D19750223T070000Z;BYDAY=3D-1SU;BYMONTH=3D2
> END:DAYLIGHT
> BEGIN:DAYLIGHT
> TZNAME:EDT
> DTSTART:19760426T020000
> TZOFFSETFROM:-0500
> TZOFFSETTO:-0400
> RRULE:FREQ=3DYEARLY;UNTIL=3D19860427T070000Z;BYDAY=3D-1SU;BYMONTH=3D4
> END:DAYLIGHT
> BEGIN:DAYLIGHT
> TZNAME:EDT
> DTSTART:19870405T020000
> TZOFFSETFROM:-0500
> TZOFFSETTO:-0400
> RRULE:FREQ=3DYEARLY;UNTIL=3D20060402T070000Z;BYDAY=3D1SU;BYMONTH=3D4
> END:DAYLIGHT
> BEGIN:DAYLIGHT
> TZNAME:EDT
> DTSTART:20070308T020000
> TZOFFSETFROM:-0500
> TZOFFSETTO:-0400
> RRULE:FREQ=3DYEARLY;BYDAY=3D2SU;BYMONTH=3D3
> END:DAYLIGHT
> BEGIN:STANDARD
> TZNAME:EST
> DTSTART:20071101T020000
> TZOFFSETFROM:-0400
> TZOFFSETTO:-0500
> RRULE:FREQ=3DYEARLY;BYDAY=3D1SU;BYMONTH=3D11
> END:STANDARD
> END:VTIMEZONE
> BEGIN:VEVENT
> UID:ce58a6ba5403da842e0b73a7dc5adb40a5fa635d
> DTSTAMP:20201215T214823Z
> DTSTART;TZID=3DAmerica/New_York:20201216T100000
> DTEND;TZID=3DAmerica/New_York:20201216T110000
> SEQUENCE:2
> ORGANIZER;CN=3DJames Toebes:mailto:james.toe...@xyleminc.com
> ATTENDEE;CUTYPE=3DINDIVIDUAL;ROLE=3DREQ-PARTICIPANT;PARTSTAT=3DNEEDS-ACTION=
> ;
> RSVP=3DTRUE;CN=3D{redacted}:mailto:{redacted}
> SUMMARY:Review Public IP in CoH
> TRANSP:OPAQUE
> CLASS:PUBLIC
> CREATED:20201215T214817Z
> LAST-MODIFIED:20201215T214817Z
> X-EVOLUTION-CALDAV-ETAG:2020-12-15T21:48:17Z
> END:VEVENT
> END:VCALENDAR
> _______________________________________________
> evolution-list mailing list
> evolution-list@gnome.org
> To change your list options or unsubscribe, visit ...
> https://mail.gnome.org/mailman/listinfo/evolution-list
This probably won't help you much, but this points to differing encoding
standards in the various environments.
=3D is the "printed-quotable" way of representing the = ("equals") character.
You see this a lot when URLs are included in email text, notably for less-than
("<") symbols. =3D is the printed-quotable format for hexadecimal 3D which is
decimal 61, which is the ASCII code for the = symbol. You can see this same
substitution happening everywhere else in your text where there is an "=".
So, that's what is happening. I can't help you with why it's happening. Is this
affecting any of the other instances where this substitution occurs, say
"organizer"?
But I'd be more concerned about this pair of lines:
> TZOFFSETFROM:-0500
> TZOFFSETTO:-0400
--
Chris_______________________________________________
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
