I rarely deal with ical but I'm glad Alpine knows how to display ical entries.
I've noticed times reported as "Eastern Standard Time" even if they are actually in "Easter Daylight Savings Time". In this message I explore why. Here's an example: Start Date: Wed 2022-10-12 09:30 AM (Eastern Standard Time) End Date: Wed 2022-10-12 10:20 AM (Eastern Standard Time) Those are really Eastern Daylight Times. The time is right for EDT. Here's what I've been reading about the ical standard with respect to timezones: <https://icalendar.org/iCalendar-RFC-5545/3-6-5-time-zone-component.html> Here's an example of the timezone part of an ical entry that displays incorrectly in Alpine. It was generated by some Microsoft thing. I have added indention to make the structure clear. BEGIN:VTIMEZONE TZID:Eastern Standard Time BEGIN:STANDARD DTSTART:16010101T020000 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3 END:DAYLIGHT END:VTIMEZONE It would make more sense if the STANDARD and DAYLIGHT sections contained TZID. The ical standard allows this but does not require this. Microsoft doesn't seem to generate these optional TZIDs. What can/should Alpine do? - lobby ical to make tzid mandatory standardc and daylightc sections. Not likely to happen and even if it did, it would take a long time to filter down to implementations. - does Alpine even know if daylight time is in effect for a particular date? - does Alpine know the daylight name of the timezone (clearly not the TZID)? Is it easy to derive one? I do think something should be done since the current displayed timezone is actually incorrect for times falling in daylight dates. _______________________________________________ Alpine-info mailing list Alpine-info@u.washington.edu http://mailman12.u.washington.edu/mailman/listinfo/alpine-info