On Wed, Apr 13, 2022 at 09:23 PM, Bruce Bowman wrote:

Andy -- How did you do this?

I open the image or file to display the contents and then do a screen capture (I use Greenshot but the Windows Snipping Tool works just as well - I'm sure there are others). From within the utility you use, copy that image to the clipboard and then paste it into the edited message.

Regards
Andy

On Wed, Apr 13, 2022 at 09:47 AM, Andy Wedge wrote:

The comparison shows changes to text but does not show insertion of embedded images or make reference to the fact they have been added.

Andy -- How did you do this? I didn't know it was possible to add an image after the fact, embedded or otherwise.

Regards,
Bruce

Hi Mark,

the member's manual states:

"In the archive, a blue Edited () badge appears next to the message, at the far right under the original timestamp. All group members can click that badge to see the message’s history and, if desired, compare revisions"

The comparison shows changes to text but does not show insertion of embedded images or make reference to the fact they have been added.   If an embedded image is removed during an edit, the comparison states that an attachment has been deleted.

Regards
Andy

oops - title should read “wording tweak”

--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu

The wording of the activity log entry when a mod changes a Member Notice parses badly. It reads "changed group member notice." I'd leave out the word "group." As you start to read the entry, it initially sounds like the mod did something to a group member. The meaning becomes clear as you finish reading the phrase, but leaving out "group" would be immediately clearer and would also match the element affected, which is called in all other contexts a "Member Notice," not a "grouip member notice."
--
J

Messages are the sole opinion of the author, especially the fishy ones.
My humanity is bound up in yours, for we can only be human together. - Desmond Tutu

Changes to the site this week:

April 8, 2022:

• NEW: Updated sort by option for photo albums. Discussion
• CHANGE: We have always ignored some calendar invite responses (Accepted/Tentative/etc), but not others. We now ignore all of them.

April 7, 2022:

• NEW: Ability to view individual Group Sponsorship and Donation Payment receipts from the Account > Billing page.
• SYSADMIN: Switched the Elasticsearch cluster to use dedicated coordinator nodes, to avoid further issues with frozen data nodes not being removed from queries.

April 6, 2022:

• NEW: When changing your account password, log out of any other session, as a security measure.
• NEW: We no longer allow email addresses from the following free top level domains: ".tk", ".ml", ".ga", ".cf", ".gq"
• CHANGE: Removed the daylight savings time information from the timezone dropdowns. Discussion

April 5, 2022:

• NEW: Renamed the activity log Expired Topic to Expired Hashtag and we are now including the hashtag that expired in the log entry (new log entries only). Discussion
• BUGFIX: Lock On Post did not work if the message was moderated. Discussion
• CHANGE: Add additional warnings/information to the account page where you can enable two factor authentication. Discussion

April 4, 2022:

• BUGFIX: We were not checking whether a user had permission to close or delete a chat (they must be the creator of the chat or a group moderator).
• INTERNAL BUGFIX: Fixed a race condition that lead to a deadlock in the webhookd process.

March 29, 2022:

• BUGFIX: Directory search was not working. Discussion

March 28, 2022:

• BUGFIX: Changing a topic's hashtags would not be reflected correctly in the activity log entry. Discussion

The next #changelog will be published on Friday, April 15th.

Take care everyone.

Mark

On Thu, Apr 7, 2022 at 12:38 PM, Andy wrote:

Currently, Microsoft Windows shows me the wrong time offset

Windows has a setting for "observe DST" (or similar) that you can set.  If you do it correctly, the displayed time will be correct, but it will still say your time zone is, for example, UTC-06:00, Central Time.  I think Microsoft got as confused as some others by the difficulty of getting it right all the time, so just made a choice and stuck with it. ;>)

Duane

On Thu, Apr 7, 2022 at 12:44 PM, Chip Davis wrote:

For half of the year, the UTC-offset in the "Timezone" list is wrong, ...

But that's the thing.  In (about) half of the places I look, the offset is right; and in the other half it is wrong.

Currently, Microsoft Windows shows me the wrong time offset, and Groups.io's Calendar shows me the currently-correct time offset.  Yet they both refer to the same time zone, the one that is currently in effect here.

I'm pretty handy with Zulu/UTC and converting between time zones.  But it is distressing seeing inconsistency in how they are listed.

Andy

This problem is caused by conflating two values, one geographical and unchanging, with one governmental that changes twice a year.  Or doesn't.

The Calendar "Timezone" drop-down list should display only that: the timezone of the location in which the event is being scheduled.  No one needs to know the UTC-offset or DST status to make an entry in the calendar.  They simply want to schedule a meeting four months from now at 11:00am in Chicago.

For half of the year, the UTC-offset in the "Timezone" list is wrong, which confuses two groups of users:
 1. Those who don't know what it means but know that it doesn't match their computer's Date/Time setting.
 2. Those who do know what it means and can't find the correct UTC-offset in the list.

There are two ways to properly handle this issue:
 1. Make the "Timezone" drop-down list smart and display the appropriate DST-dependent values (UTC-offset, timezone name and abbreviation) to accurately reflect the date being scheduled.  That's the way the calendar on my Android phone works.  That's not a SMOP for Groups.io, given the lack of reliable user location data.
 2. Remove all DST-dependent references (now only UTC-offset) from the "Timezone" drop-down list.

If users really needs to know their location's UTC-offset for any reason, Google is their friend.

-Chip-

On Thu, Apr 7, 2022 at 10:05 AM, Andy wrote:

... and that they are not consecutive.  ...

Sorry, "consecutive" was not the right word.  My mistake.  I should have written "increasing" or "monotonic".

Gaps in the numbers are normal.

Andy

For me, Windows tells me that my time zone is "(UTC-05:00) Eastern Time (US & Canada)", where the words are a reasonably good way of putting it in terms that even most Americans can understand -- even though it has the wrong time offset for most of the year.  It is puzzling that I am about as likely to see it written as either "UTC-04:00" or "UTC-05:00", where they both mean the same exact thing.  One would have thought that the 'experts' should have figured this out by now.  But I put too much faith in them.

Even more confusing is when I see it written as "UTC+05:00" but it means the same time zone.  I'm pretty sure that's wrong, but I have seen it.  Recently, in fact.  Arrgh!

Andy

I am writing this quickly, without having done much research into the problem yet.

If I click on the link "View/Reply Online (#nnnnnn)" at the bottom of the email message I receive from a group, it should take me to that message in the web interface, where I can reply to it.  It has always worked before.

This morning, it doesn't.

Upon further investigation, I see that some of the message numbers have apparently changed overnight, and that they are not consecutive.  What's going on?

The message I wanted to reply to was numbered #137348 in the email.  Today, in the web interface, it is numbered #137349   Therefore, clicking on the link in the email for #1337348 brought me to the wrong message to edit.

Not only that, but the numbers in messages of a single conversation (in my emails) are like this:

137329
137336
... (several more)
137345
137346
137347
137348
137348  NOT A TYPO
137350
137346  NOT A TYPO
137352
137353

You'll see that two of the numbers were used twice, and one of them actually goes down instead of up.

It looks like the only thing wrong, may be the message number at the bottom of the emails.  Somehow, groups.io inserted the wrong message numbers in (at least) two cases.  They are links to the wrong messages.

The messages in question happened consecutively with no overlap.  e.g., the one labeled as the second 137346 was sent as a reply to the first 137346 which was posted 90 minutes earlier (and it even quotes the contents of the earlier #137346 message).  So it's not a case of messages arriving in jumbled order.

Thanks,
Andy

On Thu, Apr 7, 2022 at 07:13 AM, Chip Davis wrote:

I have no doubt that most Americans have no clue (or care) what their GMT-offset is

Other than pilots, military, and amateur radio operators (in general), that's probably true.  (As a retiree, day or night is close enough for me...)  One solution is to list times as GMT/BST, CST/CDT, etc. without the UTC reference.  Hopefully people would understand that the calendar will adjust itself for the time of year (when sending reminders and such) so you don't need to change the scheduled time to offset for it.  Even better would be to omit any reference to summer/daylight, standard, or UTC time as Chip has mentioned, resulting in basically a 'local' time.  You'd only have AT(Atlantic Time) or GT(Greenwich Time), though there are many areas where there is no official minimalist name for the time zone.  A third scenario would be for the calendar to keep track of the time zone that would be in use for any date so that the drop down list would have the correct UTC offset (a nightmare! ;>).  Any option would likely require some serious time investment.

Duane
currently CDT

That was exactly the argument in my original #suggestion, Jeremy.

I accepted Mark's partial solution as an improvement, if not his weak "Google Calendar does it that way" argument for it.  Groups.io was supposed to be an example of doing online global collaboration right, not just a "Mailman++".

Pardon my ethnocentricity, but I have no doubt that most Americans have no clue (or care) what their GMT-offset is, so his partial solution is (sadly) acceptable for the US market.  But there is really no valid argument for listing the wrong GMT value in a drop-down list meant for the entire world.

-Chip-

The problem with keeping the UTC offsets is that about half the time they are wrong. While (using my time) today it is correctly United Kingdom Time (UTC+01:00), skipping forward to a November date (when we will be back on Winter Time = GMT = UTC+00:00), that will be wrong. So setting time for a new event, should I choose that (United Kingdom Time (UTC+01:00)), or find a different drop down entry, which has UTC+00:00.?

To my mind UTC offsets should only be there for times which are actually defined that way (or are by definition tied to a specific offset, e.g. GMT, BST, EST, AEDT). Where time is for country or city (where the offset will or may change), it should be omitted, reliance being placed on the software to sort things out) 

Jeremy

When viewing a group's Photo albums, the choices for sort order are by Title, or by Created date/time.

Can Updated date/time be a sort order option too?

Updated date/time makes the most sense to me.  When someone uploads a photo to an existing album, you might want that album to appear first in the list of albums.  But it might be nowhere near first, and might not even be on the first page of albums,  That makes it a challenge to find it, unless we can sort by the Updated date.

(Speaking of which -- Isn't it odd that we can sort the albums according to their Created date, but it's impossible to SEE what is the Created date?  Why bother sorting by something that is hidden?  What am I missing?)

Andy

That's a fair compromise, Mark.  Most non-pilot, non-global-travelers I know, don't have a clue what their UTC-offset is anyway.  The major source of confusion was due to the entries specifying a specific DST setting that was not correct for the date in question.

Thank you for seeing the value in the suggestion,

-Chip-

Having spent several long afternoons manually deleting many hundredds of obsolete photos and images, including those originating from old signature files, I agree as well.  We currently moderate attachments, and that has been helpful in terms of keeping things under control since the great purge.  Please implement this feature for files and photos.