Re: [111attendees] Agenda pains

Carsten Bormann <> Fri, 30 July 2021 10:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E23BF3A25D9 for <>; Fri, 30 Jul 2021 03:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0VyFQJ6v4Ndq for <>; Fri, 30 Jul 2021 03:50:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 23ECF3A258C for <>; Fri, 30 Jul 2021 03:50:24 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4Gbkgx6DM3z33wC; Fri, 30 Jul 2021 12:50:21 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Fri, 30 Jul 2021 12:50:21 +0200
Cc: "" <>
X-Mao-Original-Outgoing-Id: 649335021.533363-042bf27766bc131ebacdf55533f7f3c1
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Yoav Nir <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [111attendees] Agenda pains
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mailing list for IETF 111 attendees <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Jul 2021 10:50:28 -0000

On 2021-07-29, at 18:11, Yoav Nir <> wrote:
> I think UTC is best because it’s predictable and sort-of universal.

It also happens to be the standard.

(The waters are muddied because corporations trying to dumb down their communication, including the press, tend to call it GMT, which is close.  Hence people on the street are more likely to know “GMT” than “UTC”.)

Call it “world time” and it is unambiguous (“1500Z” == “1500 world”) and has the lowest number of syllables.

Being able to operate in world time is a skill that is becoming ever more important to many of us, so we might want to get with the program.

> Meeting local timezone is at least predictable when you know where the meeting “is”

"Meeting local” timezone is meaningless for anyone except at the meeting location.  Nobody is actually at the virtual meeting location, so why waste time with this?  (Once we go hybrid and use printed schedules again, the “browser time” of the printed schedule is the “meeting local” time, though.  But that is only relevant for printed matter; it MUST never be used for online information.)

> Local is most convenient, but only if it is set correctly.  

“Browser local” is probably a more accurate term.  If the timezone on your computer (which is what the browser uses) is not set to your local time, you might have a problem, but not just with IETF meetings :-)

Re the +1 notation:  There is a simpler way, used on my eclectic schedule:

1900-2100  Session I
2130-2230  Session II
2300-2500  Session III

If you can count, this should work for you.
(Not too great with negative, so once we meet on Tonga = UTC+13, we’ll need to get used to some modulo arithmetic:

9900-0100  Session 1
0130-0230  Session 2
0300-0500  Session 3

I’m not sure Tonga is on the shortlist; Auckland in Winter [Northern Summer] might be, though.)

Grüße, Carsten