[Alpine-info] ical display confuses me about timezones.

[Bret Busby]

On 17/9/22 00:23, D. Hugh Redelmeier wrote:

> 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.


I think it far simpler to avoid the use of timezone names, and instead, 
use the UTC (/GMT) increment/decrement, as shown in viewing applicable 
times in the full header display.

In the above message, the timestamp is shown as my local time (without 
the UTC/GMT increment/decrement), as
  17/9/22 00:23 (as shown in my signature, my timezone is UTC+0800)
and, if I display using the full header, the timestamp shows as
Fri, 16 Sep 2022 12:23:46 -0400 (EDT)

Whilst that is from Thunderbird, that I use for viewing and responding 
to messages, before downloading them from my web hosting mailserver, and 
then I use alpine for downloading the messages and then, doing things to 
the messages, including responding to them, once downloaded, the same 
applies in alpine; message timestamps are shown in the local timezone 
time, when using the normal headers, and, shown relative to UTC, when 
displayed using full headers.

With the Internet, that has been in existence for decades, after it 
evolved from ARPAnet, everyone who expresses a time, should express it 
in terms of UTC, and, the obstinate persistent use of local timezone 
names (I often see times for online events, with invitations to attend, 
and/or participate, expressed in EDT or PDT or, some other, deliberately 
obscured time), is purely arrogant parochialism.

The Internet brought us internationalism, that some have refused to accept.

So, any times that are expressed via the Internet, should be expressed 
in terms of UTC/GMT, so that everyone knows what is the applicable time, 
instead of hiding times in deliberately obscure timezone name references.

In Australia, we also have EST and EDT (usually, but, not always, it is 
expressed as AEST and AEDT, respectively), and, here, we have WST (which 
is, as my signature shows, UTC+0800), and, in Australia, the timezone 
names are mostly expressed without the leading 'A', so, it can all be 
unnecessarily confusing, deliberately made confusing, by arrogant people 
who refuse to state times in terms of UTC. And, in Australia, some 
states impose "daylight saving time" (which is falsely named), and, 
some, even in the same physical timezone as some that do impose it, do 
not impose it, so, EST and EDT may apply concurrently. Th whole concept 
is simply stupid, designed specifically, to confuse and cause harm.

So, all event times that are communicated via the Internet, or, 
otherwise, into different timezones, would be mandatorily expressed in 
terms of UTC, and, not in terms of arrogantly parochial local timezone 
names, that are meaningless to people who are not familiar with 
parochial timezone names, and, when the arrogant parochial people change 
their applicable times, purely for the sake of aggravating the confusion 
and harm.

And, therefore, software should express all times, in terms of UTC.

We ARE supposed to have left behind, the Dark Ages, and, entered the age 
of enlightenment and computers and the Internet.

Unfortunately, the people in power, are doing their damnedest, to keep 
us in the Dark Ages, like the obsession of the Australian governments, 
with promoting the extraction and burning of fossil fuels ("Who cares 
what harm it does, including how many people, it kills - it makes us 
politicians rich, from the money paid to us, by our friendly fossil fuel 
companies").

So, people involved in software development, should be trying to get 
themselves out of the Dark Ages, and, into the age of the Internet, by, 
amongst other things, mandating the expression of times, in terms of 
UTC, for openness and clarity.

..
Bret Busby
Armadale
West Australia
(UTC+0800)
..............