From rvi at sci.fi Sat Sep 3 08:30:34 2022 From: rvi at sci.fi (Riku Virtanen) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] An issue of Sentmail folder Message-ID: <4b231ea-e9b5-6f73-20f6-2d21641a2247@sci.fi> Dear folks, I have an issue in the names in folders. In my Linux Alpine, Sentmail folder shows who is the recipient. In Windows Alpine 2.25, Sentmail shows who is the sender. The sender is mine in all mails. How could I change that? I would like to change that I see recipients in the folder, not only my own name. In other folders, recipients are shown, and this issue relates only to Sentmail folders. Riku From alpine.chappa at yandex.com Sat Sep 3 12:17:20 2022 From: alpine.chappa at yandex.com (Eduardo Chappa) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] An issue of Sentmail folder In-Reply-To: <4b231ea-e9b5-6f73-20f6-2d21641a2247@sci.fi> References: <4b231ea-e9b5-6f73-20f6-2d21641a2247@sci.fi> Message-ID: On Sat, 3 Sep 2022, Riku Virtanen wrote: > I have an issue in the names in folders. > In my Linux Alpine, Sentmail folder shows who is the recipient. > In Windows Alpine 2.25, Sentmail shows who is the sender. The sender is mine in > all mails. > How could I change that? I would like to change that I see recipients in the > folder, not only my own name. > > In other folders, recipients are shown, and this issue relates only to Sentmail > folders. Dear Riku, by default Alpine shows you sent the message, unless it is yours and in that case it will show who you sent it to. The key issue here is that Alpine does not know that the message is yours. In order to tell Alpine that you sent the message, add your email addresses to the Alternate Addresses configuration option, which you can get to by pressing "M S C". I hope this helps. -- Eduardo From hugh at mimosa.com Fri Sep 16 09:23:46 2022 From: hugh at mimosa.com (D. Hugh Redelmeier) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] ical display confuses me about timezones. Message-ID: <9159ab91-23a6-e599-f42c-f20d57faca@mimosa.com> 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: 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. From bret at busby.net Fri Sep 16 11:53:22 2022 From: bret at busby.net (Bret Busby) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] ical display confuses me about timezones. In-Reply-To: <9159ab91-23a6-e599-f42c-f20d57faca@mimosa.com> References: <9159ab91-23a6-e599-f42c-f20d57faca@mimosa.com> Message-ID: <1e2acbc4-9517-4689-d024-aa9b3a43f6ad@busby.net> 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: > > > 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) .............. From hugh at mimosa.com Fri Sep 16 12:23:18 2022 From: hugh at mimosa.com (D. Hugh Redelmeier) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] ical display confuses me about timezones. In-Reply-To: <1e2acbc4-9517-4689-d024-aa9b3a43f6ad@busby.net> References: <9159ab91-23a6-e599-f42c-f20d57faca@mimosa.com> <1e2acbc4-9517-4689-d024-aa9b3a43f6ad@busby.net> Message-ID: <5758858-5375-8da-9bb5-16e0f8ffb84b@mimosa.com> | From: Bret Busby | 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. I think that it might be simpler to stop Earth spinning :-) 1. people are accustomed to quantized solar time. (Time Zones were initiated by a guy in my town, Toronto. He was a train guy and time zones made train schedules work better.) 2. much of my communication is local, within my timezone. Especially stuff that requires synchronization. 3. email has always had times with timezones 4. ical deals with timezones. Alpine should deal better with ical timezones. Off topic: Unix and its successors use UTC internally (as much as you can tell). Too bad MSDOS and subsequently Windows do not. From bret at busby.net Fri Sep 16 12:45:59 2022 From: bret at busby.net (Bret Busby) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] ical display confuses me about timezones. In-Reply-To: <5758858-5375-8da-9bb5-16e0f8ffb84b@mimosa.com> References: <9159ab91-23a6-e599-f42c-f20d57faca@mimosa.com> <1e2acbc4-9517-4689-d024-aa9b3a43f6ad@busby.net> <5758858-5375-8da-9bb5-16e0f8ffb84b@mimosa.com> Message-ID: <33d983c0-7621-3985-70c8-3927da3b96f7@busby.net> On 17/9/22 03:23, D. Hugh Redelmeier wrote: > | From: Bret Busby > > | 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. > > I think that it might be simpler to stop Earth spinning :-) > But, if that is done, the gravity of the situation, becomes even more significant... .. Bret Busby Armadale West Australia (UTC+0800) .............. From bret at busby.net Fri Sep 16 13:26:18 2022 From: bret at busby.net (Bret Busby) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] ical display confuses me about timezones. In-Reply-To: <5758858-5375-8da-9bb5-16e0f8ffb84b@mimosa.com> References: <9159ab91-23a6-e599-f42c-f20d57faca@mimosa.com> <1e2acbc4-9517-4689-d024-aa9b3a43f6ad@busby.net> <5758858-5375-8da-9bb5-16e0f8ffb84b@mimosa.com> Message-ID: On 17/9/22 03:23, D. Hugh Redelmeier wrote: > | From: Bret Busby > > | 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. > > I think that it might be simpler to stop Earth spinning :-) > > 1. people are accustomed to quantized solar time. (Time Zones were > initiated by a guy in my town, Toronto. He was a train guy and > time zones made train schedules work better.) > > 2. much of my communication is local, within my timezone. Especially > stuff that requires synchronization. > > 3. email has always had times with timezones > What "has always been" is not necessarily right. For far too long, in Australia, domestic violence was, and, still is, regarded as acceptable. I remember, some years ago, an Australian state supreme court ruling, that, if a wife did not want to have sexual intercourse with her husband, it was his right to use force, to have his way with her. In Australia, for also, far too long, smoking tobacco was regarded as normal and acceptable. The federal government, I believe, paid subsidies to tobacco farmers, to keep them producing tobacco. In the last couple of years, a new, major coal mine has been approved in a sinister state in Australia; the Adani Carmichael mine. The effects of the coal that it will release into the world, will, over its lifetime, amongst other things, kill more people than the registered number of deaths at Auschwitz. Coal is good and healthy, and, has always been good and healthy, and will always be good and healthy. Just ask the Australian governments, past and present. In this state, most of the motor vehicles on the road, are unroadworthy. The state has not had, and, will not have, mandatory roadworthiness testing of motor vehicles. It is the way that it has been, and, it is the way that it will be. Public safety is of no consequence. In Australia, every year, the governments set fire to the environment. It kills the fauna and flora, releases all kinds of poisons into the air (including dioxins - like Agent Orange, as used in Vietnam), and, significantly boosts global warming. It is unsafe to go outside, or, to let any air into a person's house, in capital cities, and, it causes major health problems to the public. It is that way that it is, the way that it has been, and, the way that it will be. Australia is controlled by pyromaniacs (and, that is only one of their evils). In many countries, including Australia and the USA, slavery has been regarded as acceptable, and, a normal part of life. One term that has been applied, to one of the types of slavery in Australia, is "blackbirding", where, as for USA slavery, where they abducted people from Africa, to force them into slavery, apparently, for blackbirding, Australian slavers would abduct people from the Pacific Islands (that the Australian feral parliament is pretending to be trying to make friends with, now), and, force them into slavery in Australia. Putin's invasion of the Ukraine, in his act of forced imperialism, like the Chinese emperor trying to take Taiwan (about which, the world keeps persistently silent), is like the UK having forced Northern Ireland and Scotland to be part of the UK, and, the government of England will not release them from their bondage. It is all imperialism, like the French refusing to release New Caledonia. Why are these things so? Because, it is the way that it has been, the way that it is, and, the way that it will be, because people insist that things should stay the way that they are, solely for the reason that that is the way things are. But, just because something is the custom, does not make it right. It reminds me of a sentence I heard a man say in a "Western" movie (it much reflects the current nature of the USA) - "They should never have learned women to read, coz then, they started to think". So, just because things are the way that they are, does not justify preventing change for the better. It also reminds me of a quote, that was reworded to be used by one of the USA Kennedy presidents; the original quote, from a literary work, wherein the serpent said to Eve, "You see things that are, and ask "why?"; I dream of things that never were, and, ask, "why not?" ". So, I see no justifiable reason, for times conveyed via any electronic media, to not be mandatorily expressed in terms of UTC. .. Bret Busby Armadale West Australia (UTC+0800) .............. From robin.listas at telefonica.net Fri Sep 16 13:52:12 2022 From: robin.listas at telefonica.net (Carlos E. R.) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] ical display confuses me about timezones. In-Reply-To: References: <9159ab91-23a6-e599-f42c-f20d57faca@mimosa.com> <1e2acbc4-9517-4689-d024-aa9b3a43f6ad@busby.net> <5758858-5375-8da-9bb5-16e0f8ffb84b@mimosa.com> Message-ID: On 2022-09-16 22:26, Bret Busby wrote: > So, I see no justifiable reason, for times conveyed via any electronic > media, to not be mandatorily expressed in terms of UTC. That will not happen. The only solution is to have our software deal with the existing situation. It is the only thing we can do. Focus, please. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 209 bytes Desc: OpenPGP digital signature URL: From alpine.chappa at yandex.com Fri Sep 16 18:59:11 2022 From: alpine.chappa at yandex.com (Eduardo Chappa) Date: Fri Mar 22 14:17:32 2024 Subject: [Alpine-info] ical display confuses me about timezones. In-Reply-To: <9159ab91-23a6-e599-f42c-f20d57faca@mimosa.com> References: <9159ab91-23a6-e599-f42c-f20d57faca@mimosa.com> Message-ID: On Fri, 16 Sep 2022, D. Hugh Redelmeier wrote: > 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. The sending agent added the parameter TZID with value Eastern Standard Time to the DTSTART field in the event. That is where Alpine takes this value from. This means the TZID field is incorrect from origin. I do realize, however, that it is possible to compute the correct timezone in effect at the time of the event from the VTIMEZONE description and overriding the value received by Alpine in the DTSTART field, so I will look into that and update the repository to reflect this observation. I will also look into other fields that need to be corrected. Thank you for your input. It is appreaciated! -- Eduardo