Subject: [111attendees] Agenda pains

From: "Maisonneuve, Julien (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Mon, 26 Jul 2021 17:14:06 +0000

Just one comment on the meeting agenda : I really like the "timezone" adjustment feature, it is very helpful once you get past the 100+ timezone menu.
However when you refresh the page (as you should to get updates of agendas, materials,...) you're back to the original timezone and must go again through the 100+ timezone menu each and every time.
This is a good feature, I'm sure there is a way to make it less painful.
Thanks for providing it,
Julien.

---

From: Jonathan Morton <[email-masked]>
Date: Mon, 26 Jul 2021 20:35:53 +0300

> On 26 Jul, 2021, at 8:14 pm, Maisonneuve, Julien (Nokia - FR/Paris-Saclay) <[email-masked]> wrote:
> 
> Just one comment on the meeting agenda : I really like the "timezone" adjustment feature, it is very helpful once you get past the 100+ timezone menu.  However when you refresh the page (as you should to get updates of agendas, materials,...) you're back to the original timezone and must go again through the 100+ timezone menu each and every time.

> This is a good feature, I'm sure there is a way to make it less painful.

You could hit the "Local" link just about the drop menu - that usually does the right thing.  It takes the timezone setting from your browser.

 - Jonathan Morton

---

From: "Maisonneuve, Julien (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Mon, 26 Jul 2021 17:53:51 +0000

Good catch, that solves the 100+ entries menu.
It still goes away on refresh but it's usable.
Julien.

-----Original Message-----
From: Jonathan Morton <[email-masked]> 
Sent: Monday, July 26, 2021 7:36 PM
To: Maisonneuve, Julien (Nokia - FR/Paris-Saclay) <[email-masked]>
Cc: [email-masked]
Subject: Re: [111attendees] Agenda pains

 - Jonathan Morton

---

From: yangjinze <[email-masked]>
Date: Tue, 27 Jul 2021 06:14:56 +0000

It seems that the GMT+ and GMT- time is swapped. The GMT+1 schedule actually shows GMT-1 time. I hope someone will fix this. 

Best regards,

Jinze

-----Original Message-----
From: Jonathan Morton <[email-masked]> 
Sent: Monday, July 26, 2021 7:36 PM
To: Maisonneuve, Julien (Nokia - FR/Paris-Saclay) <[email-masked]>
Cc: [email-masked]
Subject: Re: [111attendees] Agenda pains

 - Jonathan Morton

-- 
111attendees mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/111attendees

---

From: "Maisonneuve, Julien (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Thu, 29 Jul 2021 13:23:44 +0000

Thinking out loud : why not make the "local" agenda option the default ? Refreshing the agenda (to get the new WG agendas and materials) would not require returning to the page's top to resync to local.
I would assume most people use their local set timezone, so it could be positive for a significant majority.
Regards,
Julien.

-----Original Message-----
From: Jonathan Morton <[email-masked]> 
Sent: Monday, July 26, 2021 7:36 PM
To: Maisonneuve, Julien (Nokia - FR/Paris-Saclay) <[email-masked]>
Cc: [email-masked]
Subject: Re: [111attendees] Agenda pains

 - Jonathan Morton

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 29 Jul 2021 15:25:55 +0200

> Thinking out loud : why not make the "local" agenda option the default ? Refreshing the agenda (to get the new WG agendas and materials) would not require returning to the page's top to resync to l…

Why not show both local and UTC?  There is enough space!

Grüße, Carsten

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Jul 2021 15:32:37 +0200

Le 26/07/2021 à 19:14, Maisonneuve, Julien (Nokia - FR/Paris-Saclay) a
écrit :
> Just one comment on the meeting agenda : I really like the "timezone"
> adjustment feature, it is very helpful once you get past the 100+
> timezone menu. However when you refresh the page (as you should to
> get updates of agendas, materials,...) you're back to the original
> timezone and must go again through the 100+ timezone menu each and
> every time. This is a good feature, I'm sure there is a way to make
> it less painful. Thanks for providing it, Julien.

Thanks for the agenda and its organization.

With respect to time:

- at the prior IETF online meetings my local time zone was kept ok in 
the agenda displayed in the browser, despite various browsing forward 
and backward, and re-start the browser.  During this IETF if I move 
forward and come backward, or restart the browser, the time is reset.

- at the prior IETF the menu of timezones was shorter, if I recollect 
correctly.

- the notation "23:30-00:30 (+1)" might mean different things: plus 1 
day or plus one hour.

- the notation "23:30-00:30" might mean 11 o'clock if looked without 
context.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Jul 2021 15:39:44 +0200

Le 29/07/2021 à 15:23, Maisonneuve, Julien (Nokia - FR/Paris-Saclay) a
écrit :
> Thinking out loud : why not make the "local" agenda option the 
> default ?

I support this suggestion, it makes sense: make the "Local" agenda
option the default.  Currently the default is "America/Los_Angeles".

(I suspect it is the Los Angeles on the same timezone as the golden gate
bridge illustrated on the first page, because golden gate is a symbol of
San Francisco, and that is the City where the meeting should have taken
place if no covid.  But I suspect there are two San Franciscos in
"America" and only one Los Angeles.)

Alex

  Refreshing the agenda (to get the new WG agendas and
> materials) would not require returning to the page's top to resync
> to local. I would assume most people use their local set timezone, so
> it could be positive for a significant majority. Regards, Julien.
> 
> -----Original Message----- From: 111attendees 
> <[email-masked]> On Behalf Of Maisonneuve, Julien 
> (Nokia - FR/Paris-Saclay) Sent: Monday, July 26, 2021 7:54 PM To: 
> Jonathan Morton <[email-masked]> Cc: [email-masked] 
> Good catch, that solves the 100+ entries menu. It still goes away on 
> refresh but it's usable. Julien.
> 
> -----Original Message----- From: Jonathan Morton 
> <[email-masked]> Sent: Monday, July 26, 2021 7:36 PM To: 
> Maisonneuve, Julien (Nokia - FR/Paris-Saclay) 
> <[email-masked]> Cc: [email-masked] Subject:
> Re: [111attendees] Agenda pains
> 
>> On 26 Jul, 2021, at 8:14 pm, Maisonneuve, Julien (Nokia - 
>> FR/Paris-Saclay) <[email-masked]> wrote:
>> 
>> Just one comment on the meeting agenda : I really like the 
>> "timezone" adjustment feature, it is very helpful once you get
>> past the 100+ timezone menu.  However when you refresh the page (as
>> you should to get updates of agendas, materials,...) you're back to
>> the original timezone and must go again through the 100+ timezone
>> menu each and every time.
> 
> You could hit the "Local" link just about the drop menu - that 
> usually does the right thing.  It takes the timezone setting from 
> your browser.
> 
> - Jonathan Morton
>

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 29 Jul 2021 17:12:45 +0300

On Thu, 2021-07-29 at 13:23 +0000, Maisonneuve, Julien (Nokia -
FR/Paris-Saclay) wrote:
> default ? Refreshing the agenda (to get the new WG agendas and
> materials) would not require returning to the page's top to resync to
> local.

Defaulting to the timezone of the meeting locality makes sense for an
in-person meeting, since most attendees interested in any given session
will be in the same timezone as the physical session room.  For the
same reason, having the first session of the day start *not* first
thing in the morning local time usually makes sense.

Defaulting to the timezone of the accessing browser makes sense for a
virtual meeting, since almost all attendees interested in any given
session want to know how to fit the session attendance into their daily
routine.  This is, of course, the situation we presently face.

The most vexing aspect of the current agenda layout is that the
timezone of each quoted session time is not stated adjacent to the time
itself, only in the header which is generally quite a long way from any
of the times being looked for.  This makes it disturbingly easy to
misinterpret the times, whatever zone they are in.

I would support a change to show both meeting-local and browser-local
times (if different), with the timezone of each quoted directly
alongside the times.  Eg. 12:00-13:00 PDT, 22:00-23:00 EEST.  If space
permits, quoting the UTC time as well would be useful in some contexts
(eg. coordinating multi-zone groups of colleagues).

For those cases where timezone differences result in a change of date,
ambiguity could be eliminated by quoting it as (+1d) instead of just
(+1), or by directly quoting the actual day-of-week in brackets.

 - Jonathan Morton

---

From: Yoav Nir <[email-masked]>
Date: Thu, 29 Jul 2021 17:45:23 +0300

> On 29 Jul 2021, at 16:23, Maisonneuve, Julien (Nokia - FR/Paris-Saclay) <[email-masked]> wrote:
> 
> Thinking out loud : why not make the "local" agenda option the default ?

Because when you change to local time manually, you see the box where it says your time zone and make sure it’s right.

When I browse the web at work, I keep getting ads for car dealerships in Cork, because that’s the way the VPNs at my company are set up.  I don’t know where the IETF agenda picks up the local time, but I wouldn’t blindly trust it to be correct.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 29 Jul 2021 16:49:59 +0200

No idea who and how the rules to decide which city is used to
represent a particular TZ. I would guess Los Angeles was
choosen because it is the largest city in CA in DST, whereas
San Francisco is just the fourth largest. 

Cheers
    Toerless

On Thu, Jul 29, 2021 at 03:39:44PM +0200, Alexandre Petrescu wrote:
> > <[email-masked]> On Behalf Of Maisonneuve, Julien (Nokia
> > - FR/Paris-Saclay) Sent: Monday, July 26, 2021 7:54 PM To: Jonathan
> > Morton <[email-masked]> Cc: [email-masked] Subject: Re:
> > [111attendees] Agenda pains
> > 
> > -----Original Message----- From: Jonathan Morton <[email-masked]>
> > Sent: Monday, July 26, 2021 7:36 PM To: Maisonneuve, Julien (Nokia -
> > FR/Paris-Saclay) <[email-masked]> Cc:
> > [email-masked] Subject:
> > You could hit the "Local" link just about the drop menu - that usually
> > does the right thing.  It takes the timezone setting from your browser.
> > 
> > - Jonathan Morton
> > 
> 
> -- 

-- 
---
[email-masked]

---

From: "Maisonneuve, Julien (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Thu, 29 Jul 2021 15:03:36 +0000

Well, the alternative of being back to the meeting's local timezone is almost certainly worse.
J.

---

From: Oscar Garcia <[email-masked]>
Date: Thu, 29 Jul 2021 12:30:44 -0300

Julien,
I agree with your suggestion.
Best,
Oscar

---

From: Youngkwon Lim <[email-masked]>
Date: Thu, 29 Jul 2021 15:43:06 +0000

Here is my two cents. 

A SDO I'm working for uses an online calendar system to distribute agenda and meeting schedule, which has following features
- web interface for add/remov/edit the events
- setting a time zone for viewing/editing the events
- selecting different colors for each groups for web viewing
- filtering option for events according to the group
- automatic online synchronization with widely used calendar system (e.g. outlook, google calendar, ical,...)

So, the group chairs add the event to the online calendar and my outlook shows the events according to the timezone of my operating system is using automatically. Quite convenient to both the chairs and attendees.

Sincerely,
Young. 

-----Original Message-----
From: 111attendees <[email-masked]> On Behalf Of Oscar Garcia
Sent: Thursday, July 29, 2021 10:31
To: Maisonneuve, Julien (Nokia - FR/Paris-Saclay) <[email-masked]>; Jonathan Morton <[email-masked]>
Cc: [email-masked]
Subject: Re: [111attendees] Agenda pains

Julien,

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 29 Jul 2021 11:45:30 -0400

+1

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: Yoav Nir <[email-masked]>
Date: Thu, 29 Jul 2021 19:11:48 +0300

I think UTC is best because it’s predictable and sort-of universal.

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

Local is most convenient, but only if it is set correctly.  Cork is just two timezones away from me, making the times there just plausible enough to fool me.

> On 29 Jul 2021, at 18:03, Maisonneuve, Julien (Nokia - FR/Paris-Saclay) <[email-masked]> wrote:
>

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 29 Jul 2021 12:14:26 -0400

> misinterpret the times, whatever zone they are in.

Highlighting this.  It was a notable UI/UX issue for me (many meetings
ago) until I learned of and adapted to being able to change the TZ at
the top of the page.

---

From: "Bare II, Keith" <[email-masked]>
Date: Thu, 29 Jul 2021 16:24:01 +0000

From: 111attendees <[email-masked]> On Behalf Of Toerless Eckert
Sent: Thursday, July 29, 2021 10:50 AM

> No idea who and how the rules to decide which city is used to represent
> a particular TZ. I would guess Los Angeles was choosen because it is the
> largest city in CA in DST, whereas San Francisco is just the fourth
> largest.

The "Continent/City" TZ names come from the IANA Time Zone Database.

https://www.iana.org/time-zones

The general rule is that a time zone is identified by the most populous city within an area that has historically observed the same local time.  But there is the complication that the population of cities changes over time, so the city in a TZ name might have been most populous when the TZ name was chosen, but is no longer most populous.

So in in the case of the agenda, it's using "America/Los_Angeles", the most populous city in the Western US, which uses the same local time as San Francisco, where a physical meeting would have been held.

Likewise, Eastern US uses the "America/New_York" TZ name because New York is most populous.  Even though one might think it would make more sense to use Washington, the capital city.

TZ uses location names instead of a customary time zone name like "Pacific Time" or "Central European Time" because historically a location may have used different offsets from UTC, DST rules, or a different customary time zone name.  A good friend of mine who works on the TZ database demonstrated this by showing how "Asia/Singapore" will use "Japan Standard Time" during the period Singapore was occupied by Japan during World War II.

I will agree that this is tricky when you need to try and figure out what time it is in some other city in a part of the world you are not familiar with.  For example, I have trouble remembering I need to use "Asia/Kolkata" if I need to figure out what the local time is Bangalore, India.

--Keith

On Thu, Jul 29, 2021 at 03:39:44PM +0200, Alexandre Petrescu wrote:
> (I suspect it is the Los Angeles on the same timezone as the golden 
> gate bridge illustrated on the first page, because golden gate is a 
> symbol of San Francisco, and that is the City where the meeting should 
> have taken place if no covid.  But I suspect there are two San 
> Franciscos in "America" and only one Los Angeles.)
>
> Alex
>
> > to local. I would assume most people use their local set timezone, 
> > so it could be positive for a significant majority. Regards, Julien.
> >
> > (Nokia
> > <[email-masked]>
> > > past the 100+ timezone menu.  However when you refresh the page 
> > > (as you should to get updates of agendas, materials,...) you're 
> > > back to the original timezone and must go again through the 100+ 
> > > timezone menu each and every time.
> >
> > usually does the right thing.  It takes the timezone setting from your browser.
> >
> > - Jonathan Morton
> >
>
> --

--
---
[email-masked]

---

From: "Maisonneuve, Julien (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Thu, 29 Jul 2021 16:31:50 +0000

Meh. A fixed default zone which might not even be close to the meeting or anything related to the viewer doesn't sound like an improvement.
It is definitely sad that people have computers configured for something which is not appropriate for them, but is this a reason to impose hardship on the vast majority of people for whom the locale is set the right way ?
J.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Jul 2021 20:39:19 +0200

Le 29/07/2021 à 18:24, Bare II, Keith a écrit :
> From: 111attendees <[email-masked]> On Behalf Of
> Toerless Eckert Sent: Thursday, July 29, 2021 10:50 AM
> 
>> represent a particular TZ. I would guess Los Angeles was choosen
>> because it is the largest city in CA in DST, whereas San Francisco
>> is just the fourth largest.
> 

Thanks for the clarification and the explanation.

It makes think it might be advantageos to tell IANA that there are a few 
other cities called Los Angeles in the continent America.  They are on 
different time zones.

> The general rule is that a time zone is identified by the most
> populous city within an area that has historically observed the same
> local time.  But there is the complication that the population of
> cities changes over time, so the city in a TZ name might have been
> most populous when the TZ name was chosen, but is no longer most
> populous.
> 
> So in in the case of the agenda, it's using "America/Los_Angeles",
> the most populous city in the Western US, which uses the same local
> time as San Francisco, where a physical meeting would have been
> held.

If so, then the option "America/Los Angeles" could be named
"America/Los Angeles (the most populous LA of America, as of July 29, 
2021); for SF".
> 
> Likewise, Eastern US uses the "America/New_York" TZ name because New
> York is most populous.  Even though one might think it would make
> more sense to use Washington, the capital city.
> 
> TZ uses location names instead of a customary time zone name like
> "Pacific Time" or "Central European Time" because historically a
> location may have used different offsets from UTC, DST rules, or a
> different customary time zone name.  A good friend of mine who works
> on the TZ database demonstrated this by showing how "Asia/Singapore"
> will use "Japan Standard Time" during the period Singapore was
> occupied by Japan during World War II.
> 
> I will agree that this is tricky when you need to try and figure out
> what time it is in some other city in a part of the world you are not
> familiar with.  For example, I have trouble remembering I need to use
> "Asia/Kolkata" if I need to figure out what the local time is
> Bangalore, India.

I fully agree.

Talking about places is different depending on the respective cultures. 
  If I say Los Angeles to a resident of California, certainly s/he will 
understand LA.  But to a resident of Argentina, it is not sure.

But there are means to accommodate both in a still short name.

Alex

>> Le 29/07/2021 à 15:23, Maisonneuve, Julien (Nokia -
>> FR/Paris-Saclay) a écrit :
>> (I suspect it is the Los Angeles on the same timezone as the
>> golden gate bridge illustrated on the first page, because golden
>> gate is a symbol of San Francisco, and that is the City where the
>> meeting should have taken place if no covid.  But I suspect there
>> are two San Franciscos in "America" and only one Los Angeles.)
>> 
>> Alex
>> 
>>> materials) would not require returning to the page's top to
>>> resync to local. I would assume most people use their local set
>>> timezone, so it could be positive for a significant majority.
>>> Regards, Julien.
>>> 
>>> Good catch, that solves the 100+ entries menu. It still goes away
>>> on refresh but it's usable. Julien.
>>> 
>>> <[email-masked]> Cc: [email-masked]
>>>> past the 100+ timezone menu.  However when you refresh the
>>>> page (as you should to get updates of agendas, materials,...)
>>>> you're back to the original timezone and must go again through
>>>> the 100+ timezone menu each and every time.
>>> 
>> -- 111attendees mailing list [email-masked] 
> -- --- [email-masked]
> -- 111attendees mailing list [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Jul 2021 20:45:43 +0200

Le 29/07/2021 à 16:12, Jonathan Morton a écrit :
[...]
> (+1), or by directly quoting the actual day-of-week in brackets.

I agree with the need of disambiguation; simply '+1' might mean +1hour.

+1d is possible, and there could be others.

Alex

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 30 Jul 2021 12:10:16 +0200 (CEST)

> Il 29/07/2021 20:45 Alexandre Petrescu <[email-masked]> ha scritto:
> 
>  

"(+1)" is standard notation in the airline industry, which is possibly the most common source of a scheduled activity starting on a day and ending on the following one, at least for people who travel a lot. I wouldn't expect IETF participants to find it ambiguous. 

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 30 Jul 2021 12:50:21 +0200

> 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

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 30 Jul 2021 12:57:41 +0200

Le 30/07/2021 à 12:10, Vittorio Bertola a écrit :
> 
> 
>> Il 29/07/2021 20:45 Alexandre Petrescu 
>> <[email-masked]> ha scritto:
>> 
>> 
>> Le 29/07/2021 à 16:12, Jonathan Morton a écrit : [...]
>>> For those cases where timezone differences result in a change of 
>>> date, ambiguity could be eliminated by quoting it as (+1d) 
>>> instead of just (+1), or by directly quoting the actual 
>>> day-of-week in brackets.
>> 
> "(+1)" is standard notation in the airline industry, which is 
> possibly the most common source of a scheduled activity starting on
> a day and ending on the following one, at least for people who travel
> a lot. I wouldn't expect IETF participants to find it ambiguous.

True: the airline industry often displays such +1 in timetables.  I
remember from a long past having seen +1 displayed on a seat LCD, and on
the boarding pass, during a long range passenger flight.  In French they
say (j+1) rather than (+1).

There is also the wristwatch industry using an names of timezones
inherited from airport names: 'LAX' rather than 'Pacific' or 'PDT', and
similar.

Were we to rely on air industry we'd rather use these instead of UTC.

Alex

---

From: Nigel Hickson <[email-masked]>
Date: Fri, 30 Jul 2021 12:00:14 +0100

Good afternoon

Apologies; but why not UTC?

Nigel

On Fri, 30 Jul 2021 at 11:50, Carsten Bormann <[email-masked]> wrote:

> (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”.)
>
> 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 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.)
>
> “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 :-)
>
> (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
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 30 Jul 2021 14:24:02 +0200

> Apologies; but why not UTC?

Because it is a third step in the conversion process.

Two steps are sufficient.

Alex

> 
> Nigel
> 
> On Fri, 30 Jul 2021 at 11:50, Carsten Bormann <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     On 2021-07-29, at 18:11, Yoav Nir <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>     (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”.)
> 
>     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 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.)
> 
>     “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 :-)
> 
>     (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
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/111attendees>
> 
>