Subject: Re: [Manycouches] When IETF participants are active on-line

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 1 Jun 2021 11:31:19 +0200

Le 01/06/2021 à 01:41, Brian E Carpenter a écrit :
> On 01-Jun-21 11:24, Christian Huitema wrote:
> ...
>>> Personally, I’m very loath to draw conclusions from the data in this case
> 
> Agreed
>   
>> I wonder whether Brian could get another breakout from the data. Can we
> get from the email header to the time zone used by the author of the email?
> 
> Sure, +/- daylight savings which is a pig to handle. The data look like:
>     Mon, 22 Jun 2015 17:42:27 -0700

Certainly a good appreciation of daylight savings variation is worth making.

In the graphs, it seems UTC-4 is the source of most messages.

But which countries are now on UTC-4?  My map says they are Denmark 
(Greenland), Venezuela, Bolivia, parts of Brazil, Bolivia, Paraguay, 
Chile.  Is it from these countries that these most messages were generated?

Maybe by 'UTC-4' one meant something about Summer time, which would move 
it to the East Coast of USA, East Canada, Columbia, Peru, Ecuador.  Is 
it rather this?

Maybe it is sufficient to say when the measurement was performed.

Alex

> 
>> Can we get an estimate of the number of participants per time zone?
> 
> I don't have per-participant data. messages per time zone is possible.
> 
>> And maybe some kind of indication of at what UTC time people working in
> a given time zone are sending email?
> 
> That's in the data (assuming the sending UA is in the same time zone as the human). Whether I write the code is another matter...
> 
>      Brian
> 
> _______________________________________________
> Manycouches mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manycouches
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 1 Jun 2021 08:11:19 -0700

Thanks, Brian.

Your two graphs can be used as input to evaluation algorithms, 
determining "pain level" and "users".

To determine "pain level", I would take your first graph, the one you 
call "Hour counts in origin time zone". If lots of messages are sent in 
a given hour, then that hour could be marked as "easy" -- not much pain. 
If very few are, that probably indicates a painful hour. And then in 
between values.

The second graph, "Messages per origin time zone", is harder to use. It 
tells us something that we could have guessed, with big groups 
corresponding to continents:

- Europe, Africa and the some of the Middle East, stretching from UTC+0 
(e.g., British Islands) to UTC+3 (Western Russia, parts of Middle-East, 
Western Africa).

- Eastern Asia and Australia, stretching from UTC+8 (China, Siberia, 
Indonesia, Western Australia) to UTC+13 (New Zealand, various islands in 
the Pacific)

- North and South America, stretching from UTC-8 (US Pacific coast) to 
UTC-3 (Argentina, Brazil, eastern parts of North America and the 
Caribbeans)

The zone with no messages correspond to parts of oceans with only a few 
scattered islands, but also parts of continents that have few people or 
little IETF participation. They include however parts of Russia and the 
Caucasus, the UAE, Mauritius, Reunion, Kazakhstan and central Asia, 
Western parts of China, Pakistan, India, Sri-Lanka, Myanmar, Thailand, 
Vietnam, Laos, Cambodia, Alaska, Hawaii, and Tahiti. Different people 
might have different opinion about excluding these areas from 
consideration. I am somewhat surprised in particular to not see much 
traffic from India (UTC+5:30).

As was noted, we really should consider daylight saving time when 
looking at the "Messages per origin time zone". I suspect that trying to 
do analyze the time zone tags to detect summer and winter time would be 
hard. But we normally conduct IETF meetings in March, July and November. 
It might be possible to get statistics for each of these three months.

-- Christian Huitema

On 5/31/2021 10:15 PM, Brian E Carpenter wrote:
> I tracked down a bug in my dataset extraction process. The corrected histogram follows. (The other ones I sent are also slightly off, but not seriously).
>
> Messages per origin time zone (0 = UTC, 1= UTC+1, etc.)
>   0  4345 +++++++++++++++++++++++++++++++++++++++++++
>   1  4375 +++++++++++++++++++++++++++++++++++++++++++
>   2  4882 ++++++++++++++++++++++++++++++++++++++++++++++++
>   3   737 +++++++
>   4     6
>   5    57
>   6     4
>   7    77
>   8   730 +++++++
>   9   681 ++++++
> 10   538 +++++
> 11   419 ++++
> 12   314 +++
> 13   445 ++++
> -10   85
> -9     5
> -8  3305 ++++++++++++++++++++++++++++++++
> -7  4752 +++++++++++++++++++++++++++++++++++++++++++++++
> -6   747 +++++++
> -5  4778 +++++++++++++++++++++++++++++++++++++++++++++++
> -4  6013 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> -3   440 ++++
> -2    13
> -1     1
>
> Regards
>     Brian Carpenter
> On 01-Jun-21 15:49, Brian E Carpenter wrote:
>> This tackles a harder part of Christian's questions: "Can we get an estimate of the number of participants per time zone?" Not exactly, but we can
>> see how many messages originate in each time zone. (Not considering daylight savings, which would be a horrible job.)
>>
>> This is what my dataset gives, but I am suspicious of the values for UTC+12 and UTC-11, which look too high. Regardless of that, there are at least 8 timezones with very few active contributors.
>>
>> Messages per origin time zone (0 = UTC, 1= UTC+1, etc.)
>>   0  5083 ++++++++++++++++++++++++++++++++++++++
>>   1  7928 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>   2  7777 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>   3   737 +++++
>>   4     6
>>   5    57
>>   6     4
>>   7    77
>>   8   730 +++++
>>   9   681 +++++
>> 10   540 ++++
>> 11   419 +++
>> 12  3891 +++++++++++++++++++++++++++++
>> -11 5328 ++++++++++++++++++++++++++++++++++++++++
>> -10   85
>> -9     5
>> -8  3309 +++++++++++++++++++++++++
>> -7  4758 ++++++++++++++++++++++++++++++++++++
>> -6   893 ++++++
>> -5  5211 +++++++++++++++++++++++++++++++++++++++
>> -4  6092 ++++++++++++++++++++++++++++++++++++++++++++++
>> -3   440 +++
>> -2    13
>> -1     1
>>
>> Regards
>>     Brian
>>
>>> On 5/31/2021 4:14 PM, Fred Baker wrote:
>>>>> On May 31, 2021, at 3:37 PM, John Levine <[email-masked]> wrote:
>>>>>
>>>>> It appears that John Levine  <[email-masked]> said:
>>>>>> It appears that Brian E Carpenter  <[email-masked]> said:
>>>>>>> [If anyone wants to analyse some other set of folders, the Python code is available on request, but it's not polished.]
>>>>>> I did a similar sample of the past year's mail from the IMAP list archive.
>>>>>>
>>>>>> See https://datecount.services.net/
>>>>>>
>>>>>> It shows the most popular hour as 0000 which may be an artifact of mail sent without a date.  I'll have to take
>>>>>> a look and see what the breakdown of times within that hour.  It confirms that Tuesday is a lot busier
>>>>>> than the weekend.
>>>>> Fixed it -- there's a folder of DMARC reports which are mostly sent shortly after 0000 UTC.  Now the numbers look
>>>>> more like Brian's.
>>>> There are multiple possible conclusions, one of which is that we have
> a glimmer but not enough solid data to make such a decision. Another might be that the indicated time is daylight in the US, 9:00 AM in Silicon Valley, with whatever validity that might represent.
>> get from the email header to the time zone used by the author of the email? Can we get an estimate of the number of participants per time zone? And maybe some kind of indication of at what UTC time people working in a
> given time zone are sending email?
>>> -- Christian Huitema
>>>
>>>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Jun 2021 14:05:56 -0400

One interesting bias in this count is that it doesn't count lurkers who do
not send email.   It only counts active, engaged participants who have
opinions.

People who don't have something to say, don't need to participate in real
time, and can use youtube at a time that convenient.

I don't really consider this a bug, but others might.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Jun 2021 08:32:19 +1200

> I don't really consider this a bug, but others might.

It's not exactly a bug, but since we make all our stuff public, we can probably never really determine how many people are reading but never writing. It seems reasonable (but unprovable) to assume that their diurnal cycles are roughly the same, though.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Jun 2021 08:59:43 +1200

> I am somewhat surprised in particular to not see much 
> traffic from India (UTC+5:30)

I rounded down the hour, so that would be part of UTC+5. But I agree, I would have expected more.

> As was noted, we really should consider daylight saving time

Yes, but I concluded that it's (a) a horrible job, because it means discovering the worldwide daylight savings dates for all the years covered in the dataset, and (b) impossible, because you can't tell from "Fri, 26 Jun 
2015 11:43:01 +0100" whether the person was actually in a place that uses 
daylight savings in June (e.g. the UK) or somewhere that doesn't (e.g. Abuja). Very few mail user agents tag the date with the name of the time zone.

> But we normally conduct IETF meetings in March, July and November. 

Certainly, although the DST change tends to occur during March. But my sample is a bit small. It might be more significant for John to do that.

However, none of this is absolute truth. My main takeaway is that there really isn't an ideal time of day, which we knew already.

Regards
   Brian Carpenter

>> a glimmer but not enough solid data to make such a decision. Another might be that the indicated time is daylight in the US, 9:00 AM in Silicon 
Valley, with whatever validity that might represent.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Jun 2021 09:12:38 +1200

> Certainly a good appreciation of daylight savings variation is worth making.

As I just said in reply to Christian, that is hard or impossible to do correctly.

> it to the East Coast of USA, East Canada, Columbia, Peru, Ecuador.  Is 

Indeed, the DST problem spreads the peaks in the graph. Please don't ver-interpret the data.
 
> Maybe it is sufficient to say when the measurement was performed.

My data set covers many years, as noted earlier.

   Brian

---

From: Jay Daley <[email-masked]>
Date: Wed, 2 Jun 2021 09:37:32 +1200

Here’s another dataset.  Prior to IETF 108 we issued a survey that asked people to rate the impact of meeting during two hour time slots covering the full 24 hours.  Here’s a chart of the 473 responses followed by one of the time zones of respondents.  If anyone wants the dataset then please email me offlist.

Jay

> On 2/06/2021, at 8:59 AM, Brian E Carpenter <[email-masked]> wrote:
> 

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 1 Jun 2021 22:09:07 +0000

Michael

Indeed, it does not count 'lurkers' but it may also overcount 'vocal IETF'ers' ;-)

Knowing the measure bias is always important as you know

-éric

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Jun 2021 11:02:27 +1200

Thanks for the plots. Visually, they are very similar to mine and John's. 
In other words, people prefer times when they are active anyway. This has 
a different sampling bias (this is people who chose to respond to a specific survey, and mine & John's are people who chose to send email over a stretch of time) so it's reassuring that the results are broadly concordant.

None of which helps very much if our goal is to share the pain fairly. We'd need to agree what "fairly" means.

Regards
   Brian

On 02-Jun-21 09:37, Jay Daley wrote:
> Here’s another dataset.  Prior to IETF 108 we issued a survey that asked people to rate the impact of meeting during two hour time slots covering the full 24 hours.  Here’s a chart of the 473 
responses followed by one of the time zones of respondents.  If anyone wants the dataset then please email me offlist.
> 
> 
> 
> 
> Jay
> 
> 
> 
>> On 2/06/2021, at 8:59 AM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> daylight savings in June (e.g. the UK) or somewhere that doesn't (e.g. 
Abuja). Very few mail user agents tag the date with the name of the time zone.
>> Certainly, although the DST change tends to occur during March. But my 
sample is a bit small. It might be more significant for John to do that.
>>>> I tracked down a bug in my dataset extraction process. The corrected 
histogram follows. (The other ones I sent are also slightly off, but not seriously).
>>>>> This tackles a harder part of Christian's questions: "Can we get an 
estimate of the number of participants per time zone?" Not exactly, but we
>> can
>>>>> see how many messages originate in each time zone. (Not considering 
daylight savings, which would be a horrible job.)
>>>>>>>> On May 31, 2021, at 3:37 PM, John Levine <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>
>>>>>>>> It appears that John Levine  <[email-masked] <mailto:[email-masked]>> said:
>>>>>>>>> It appears that Brian E Carpenter  <[email-masked] <mailto:[email-masked]>> said:
>>>>>>>>> See https://datecount.services.net/ <https://datecount.services.net/>
>>>>>>>>>
>>>>>>>>> It shows the most popular hour as 0000 which may be an artifact 
of mail sent without a date.  I'll have to take
>>>> a glimmer but not enough solid data to make such a decision. Another 
might be that the indicated time is daylight in the US, 9:00 AM in Silicon

---

From: "John Levine" <[email-masked]>
Date: 1 Jun 2021 21:37:25 -0400

>significant for John to do that.

I went through all of the mail on the IETF IMAP server from the past year and
made a simple-minded count of the last token in the Date: headers.

The numbers look similar to Brian's except there is a whole lot of
+0000 which might mean they're in the UK or Ireland or Iceland but
more often means that the MUA didn't know what the user's local zone
was. I didn't try to combine the counts for the various different time
zone names but it doesn't look like it'd make a lot of difference.

I think we now know that we have a lot of people from the east and west coasts
of North America and from western Europe, but we already knew that.

R's,
John

-2200   1 
-1000  27 
-0900   4 
-0800 16293 *****************************
-0700 27912 **************************************************
-0600 1171 **
-0500 8481 ***************
-0400 11162 *******************
-0300 1021 *
-0200  40 
-0100   1 
+0000 23305 *****************************************
-0000 445 
+0100 8461 ***************
+0200 8348 **************
0200   1 
+0300 1282 **
+0330   3 
+0400  37 
+0430   2 
+0500  12 
+0530 650 *
+0600   2 
+0700  94 
+0800 1275 **
+0900 913 *
+0930   2 
+1000 1027 *
+1030   2 
+1100 825 *
+1200 818 *
+1300 808 *

2000   1 
2001   2 
(EDT) 639 *
(UTC) 426 
(PDT) 999 *
(CEST) 241 
(EST) 492 
(KST)  48 
(PST) 860 *
(GMT) 257 
(CET) 180 
(GMT+08:00)  83 
(CST) 537 
(BST) 236 
(JST)  18 
(CDT)  89 
(HKT)   6 
GMT 120 
(IST)  16 
(MDT)  91 
(EET)  46 
(HST)   3 
(BRT)   1 
(EEST)   6 
PST 142 
PDT 142 
DST)  52 
EDT  16 
(EETDST)   1 
CST   1 
(MST) 104 
(GMT+03:30)   1 
(WET)   3 
(MET)  16 
MET  10 
EST   8 
CDT   3 
U   1 
11:58:13   1 
(GMT+9:00)   1 
Time)   2 
(METDST)   3 
(MEST)   4 
(MSK)   1 
21:22:39   1 
(NZST)   1 
(GMT-8)   2 
PST8   6 
08:48:47   1 
(standaardtijd))   1 
(GMT+0500)   3 
MST   1 
(AKST)   1 
EEST   1 
(ART)   1 
(YEKT)   1

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 3 Jun 2021 17:53:00 +0200

Le 01/06/2021 à 17:11, Christian Huitema a écrit :
>  call "Hour counts in origin time zone". If lots of messages are sent
> in a given hour, then that hour could be marked as "easy" -- not much
> pain. If very few are, that probably indicates a painful hour. And
> then in between values.
> 
> The second graph, "Messages per origin time zone", is harder to use.
> It tells us something that we could have guessed, with big groups 
> - Europe, Africa and the some of the Middle East, stretching from
> UTC+0 (e.g., British Islands) to UTC+3 (Western Russia, parts of
> Middle-East, Western Africa).
> 
>  Indonesia, Western Australia) to UTC+13 (New Zealand, various
> islands in the Pacific)
> 
> - North and South America, stretching from UTC-8 (US Pacific coast)
> to UTC-3 (Argentina, Brazil, eastern parts of North America and the 
> Caribbeans)
> 
> The zone with no messages correspond to parts of oceans with only a
> few scattered islands, but also parts of continents that have few
> people or little IETF participation. They include however parts of
> Russia and the Caucasus, the UAE, Mauritius, Reunion, Kazakhstan and
> central Asia, Western parts of China, Pakistan, India, Sri-Lanka,
> Myanmar, Thailand, Vietnam, Laos, Cambodia, Alaska, Hawaii, and
> Tahiti. Different people might have different opinion about excluding
> these areas from consideration. I am somewhat surprised in particular
> to not see much traffic from India (UTC+5:30).
> 
> looking at the "Messages per origin time zone". I suspect that trying
> to do analyze the time zone tags to detect summer and winter time
> would be hard. But we normally conduct IETF meetings in March, July
> and November. It might be possible to get statistics for each of
> these three months.

With respect to daylight savings time, July and November are easy: each
is always either on a daylight savings or or on a daylight 'wastings'
time if I can say so.  (it's not sure whether one wastes or not energy
by observing DST).

But March is difficult: being on DST or DWT depends on the year, on the
week and on the place.  In some years, March is on daylight savings time
time, and in other years March is on daylight wastings time (if I can
say so).  Moreover, some weeks within March are simultaneously on
savings and wastings, depending on what place one looks at from.

To facilitate the task, these dates are all planned for the next decades
or so.  It is known in advance which place and date in March are on DST.

To make it more difficult, it is not known the administrative decisions
at countries to continue or to retire from the DST observation
mechanism.  One day a country might decide to no longer observe DST.

(countries might also re-allocate on which timezone their surface
actually stretches, but that is another problem, independent of the DST
unknown).

For the purpose of the measurements of places where IETF participants
are active online: I think it might be easy to perform them in October
and June.  These measurements will give a good indicator of place and
messages sent, independent of the DST variation.  They then could be a
good predictor of choosing the online meeting timezone, or the place of
a f2f meeting, of that particular year.

It would be little appropriate to make a long term decision (e.g. the
current NA-EU-Asia for 30+ years), based on a one time measurement, I think.

Alex

>> I tracked down a bug in my dataset extraction process. The
>> corrected histogram follows. (The other ones I sent are also
>> slightly off, but not seriously).
>> 
>> Messages per origin time zone (0 = UTC, 1= UTC+1, etc.) 0  4345
>> +++++++++++++++++++++++++++++++++++++++++++ 1  4375
>> +++++++++++++++++++++++++++++++++++++++++++ 2  4882
>> ++++++++++++++++++++++++++++++++++++++++++++++++ 3   737 +++++++ 4
>> 6 5    57 6     4 7    77 8   730 +++++++ 9   681 ++++++ 10   538
>> +++++ 11   419 ++++ 12   314 +++ 13   445 ++++ -10   85 -9     5 -8
>> 3305 ++++++++++++++++++++++++++++++++ -7  4752
>> +++++++++++++++++++++++++++++++++++++++++++++++ -6   747 +++++++ -5
>> 4778 +++++++++++++++++++++++++++++++++++++++++++++++ -4  6013
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -3
>> 440 ++++ -2    13 -1     1
>> 
>> Regards Brian Carpenter On 01-Jun-21 15:49, Brian E Carpenter
>> wrote:
>>> This tackles a harder part of Christian's questions: "Can we get
>>> an estimate of the number of participants per time zone?" Not
>>> exactly, but we can see how many messages originate in each time
>>> zone. (Not considering daylight savings, which would be a
>>> horrible job.)
>>> 
>>> This is what my dataset gives, but I am suspicious of the values
>>> for UTC+12 and UTC-11, which look too high. Regardless of that,
>>> there are at least 8 timezones with very few active
>>> contributors.
>>> 
>>> Messages per origin time zone (0 = UTC, 1= UTC+1, etc.) 0  5083
>>> ++++++++++++++++++++++++++++++++++++++ 1  7928
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2
>>> 7777 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3
>>> 737 +++++ 4     6 5    57 6     4 7    77 8   730 +++++ 9   681
>>> +++++ 10   540 ++++ 11   419 +++ 12  3891
>>> +++++++++++++++++++++++++++++ -11 5328
>>> ++++++++++++++++++++++++++++++++++++++++ -10   85 -9     5 -8
>>> 3309 +++++++++++++++++++++++++ -7  4758
>>> ++++++++++++++++++++++++++++++++++++ -6   893 ++++++ -5  5211
>>> +++++++++++++++++++++++++++++++++++++++ -4  6092
>>> ++++++++++++++++++++++++++++++++++++++++++++++ -3   440 +++ -2
>>> 13 -1     1
>>> 
>>> Regards Brian
>>> 
>>>>>>>> [If anyone wants to analyse some other set of folders,
>>>>>>>> the Python code is available on request, but it's not
>>>>>>>> polished.]
>>>>>>> It shows the most popular hour as 0000 which may be an
>>>>>>> artifact of mail sent without a date.  I'll have to take 
>>>>>>> a look and see what the breakdown of times within that
>>>>>>> hour.  It confirms that Tuesday is a lot busier than the
>>>>>>> weekend.
>>>>>> Fixed it -- there's a folder of DMARC reports which are
>>>>>> mostly sent shortly after 0000 UTC.  Now the numbers look 
>>>>>> more like Brian's.
>> a glimmer but not enough solid data to make such a decision.
>> Another might be that the indicated time is daylight in the US,
>> 9:00 AM in Silicon Valley, with whatever validity that might
>> represent.
>>> get from the email header to the time zone used by the author of
>>> the email? Can we get an estimate of the number of participants
>>> per time zone? And maybe some kind of indication of at what UTC
>>> time people working in a
>>>> _______________________________________________ Manycouches
>>>> mailing list [email-masked] 
>> _______________________________________________ Manycouches mailing
>> list [email-masked] 
> _______________________________________________ Manycouches mailing
> list [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Jun 2021 07:53:41 +1200

Alexandre,

> current NA-EU-Asia for 30+ years), based on a one time measurement, I think.

That's exactly why I used a multi-year corpus of emails. But Jay's one-time survey gave a very similar result.

Regards
   Brian