Proposal: Use UTC timezone for meetings

[Rubén Martín]

Hi,

After a long discussion on mozillians list
<https://groups.google.com/forum/?fromgroups=#%21topic/mozilla.mozillians/AA7nu8_jiYI>,
I want to bring this topic here with a proposal:

"In all Mozilla meetings, always include UTC
<https://en.wikipedia.org/wiki/Coordinated_Universal_Time> times, you
can also include your local time and it's strongly recommended that UTC
time is linked to timeanddate.com
<http://www.timeanddate.com/worldclock/fixedform.html> or similar tool."

Why:

* We are a global community.
* Everyone should know in which timezone lives, expressed in UTC+/-number.
* Doing the maths is easier for everyone, specially when you already
know your difference with UTC.
* We'll avoid problems when time changes due daily saving, UTC is UTC
all the year.

Clarification: Scheduled (recurrent) meetings can be at the same local
time during the year if needed (e.g Monday meeting), it's just a matter
of remembering that UTC time will change once a year.

Regards.

--
Rubén Martín [Nukeador]
Mozilla Reps Mentor
http://www.mozilla-hispano.org
http://twitter.com/mozilla_hispano
http://facebook.com/mozillahispano

[Gervase Markham]

By posting this here, are you saying that Mozilla should have an
official policy (as opposed to, say, a best practices recommendation) on
the right way to do meeting announcements? If so, I'm not sure I agree
with that.

However, if we are going to have such a policy, I have a counter-proposal.

* Every meeting should have a time which is fixed in a particular
timezone, or in UTC. How it is fixed is at the discretion of the
organizer, but Pacific Time is recommended, to avoid twice-yearly
clashes as one lot of meetings move and another lot don't.

* Meeting announcements should specify the time in that timezone, and
only that timezone.

* Meeting announcements must also contain a link to timeanddate.com
which decodes that time into a time in the user's local timezone, so
everyone can easily find out what time it is for them.

Why?

* If you put multiple times in an announcement, they will get out of
sync when there's a DST change somewhere. From long experience, I know
this happens. Particularly unintuitive is the fact that if a meeting is
fixed in (e.g.) Pacific Time, when there's a DST change in that region
and everyone changes their clocks, you need to update the meeting
announcement to alter the _UTC_ time.

> * We'll avoid problems when time changes due daily saving, UTC is
> UTC all the year.

Only if all the meetings are _fixed_ in UTC time, which would be a big
change for Mozilla.

> Clarification: Scheduled (recurrent) meetings can be at the same local
> time during the year if needed (e.g Monday meeting), it's just a matter
> of remembering that UTC time will change once a year.

Twice a year.

Gerv

[Rubén Martín]

El 13/05/13 15:14, Gervase Markham escribió:

> By posting this here, are you saying that Mozilla should have an
> official policy (as opposed to, say, a best practices recommendation) on
> the right way to do meeting announcements? If so, I'm not sure I agree
> with that.

Uhm, probably it's a good idea to have a policy, I don't see how that
can be a bad thing. For me is part of being global and inclusive with
the rest of the community using a standard way to express times and
facilitating the work to mozillians.

>
> However, if we are going to have such a policy, I have a counter-proposal.
>
> * Every meeting should have a time which is fixed in a particular
> timezone, or in UTC. How it is fixed is at the discretion of the
> organizer, but Pacific Time is recommended, to avoid twice-yearly
> clashes as one lot of meetings move and another lot don't.
>
> * Meeting announcements should specify the time in that timezone, and
> only that timezone.
>
> * Meeting announcements must also contain a link to timeanddate.com
> which decodes that time into a time in the user's local timezone, so
> everyone can easily find out what time it is for them.
>
> Why?
>
> * If you put multiple times in an announcement, they will get out of
> sync when there's a DST change somewhere. From long experience, I know
> this happens. Particularly unintuitive is the fact that if a meeting is
> fixed in (e.g.) Pacific Time, when there's a DST change in that region
> and everyone changes their clocks, you need to update the meeting
> announcement to alter the _UTC_ time.

Pacific time goes out of sync also when it changes with the rest of the
world, there is a 2-3 weeks gap where people outside Pacific time don't
have a clue the time difference. There are a lot of countries that don't
change time, and the ones than change they do in a different moment than
Pacific. So it's also a problem for the rest of the world.

Using UTC is consistent during the year, 6 months a meeting will be at
16UTC and the other 6 at 17UTC. For countries that change the time, it
would be at the same moment most of the year (except these 2-3 weeks I
talked about).

Updating UTC time twice a year it's a small work compared with the work
you save to the rest of the community to track pacific time. We already
know in which time zone we are, which is expressed in UTC.

>
>> > * We'll avoid problems when time changes due daily saving, UTC is
>> > UTC all the year.

> Only if all the meetings are _fixed_ in UTC time, which would be a big
> change for Mozilla.

Explained in previous comment.

[Byron Jones]

Rub�n Mart�n wrote:
> El 13/05/13 15:14, Gervase Markham escribi�:

>> > By posting this here, are you saying that Mozilla should have an
>> > official policy (as opposed to, say, a best practices recommendation) on
>> > the right way to do meeting announcements? If so, I'm not sure I agree
>> > with that.
> Uhm, probably it's a good idea to have a policy, I don't see how that
> can be a bad thing. For me is part of being global and inclusive with
> the rest of the community using a standard way to express times and
> facilitating the work to mozillians.

if we're to have a policy/guidelines/recommendations surrounding dates
and times, may i suggest the following additions:
- dates should be in yyyy-mm-dd format or another non-ambiguous
format (eg. 1st jan 2013)
- seasons shouldn't be used in announcements, use quarters instead
(spring 2013 is Q4 for half of the globe)


--
byron - irc:glob - bugzilla.mozilla.org team -

[Lawrence Mandel]

----- Original Message -----
> El 13/05/13 15:14, Gervase Markham escribió:

> > By posting this here, are you saying that Mozilla should have an
> > official policy (as opposed to, say, a best practices
> > recommendation) on
> > the right way to do meeting announcements? If so, I'm not sure I
> > agree
> > with that.
> Uhm, probably it's a good idea to have a policy, I don't see how that
> can be a bad thing. For me is part of being global and inclusive with
> the rest of the community using a standard way to express times and
> facilitating the work to mozillians.

An official policy for meeting announcements seems very heavy handed to me. I agree with a best practice recommendation.

Lawrence

[Mark Banner]

On 13/05/2013 15:43, Rub�n Mart�n wrote:
> El 13/05/13 15:14, Gervase Markham escribi�:

>> By posting this here, are you saying that Mozilla should have an
>> official policy (as opposed to, say, a best practices recommendation) on
>> the right way to do meeting announcements? If so, I'm not sure I agree
>> with that.
> Uhm, probably it's a good idea to have a policy, I don't see how that
> can be a bad thing. For me is part of being global and inclusive with
> the rest of the community using a standard way to express times and
> facilitating the work to mozillians.

I believe that having a policy for everything will end up in a huge list
of policies, that we won't manage, and that will probably tend to mean
we all have to act the same way, irrespective our our individual
cultures. I've no proof of this, but that's my feeling.

I'd rather we look at what we can do to improve things for everyone, not
just a section. Hence, see the post entitled "Improving our tools for
meeting scheduling" that I'm just about to post.

Mark.

[Mark Banner]

On 12/05/2013 14:25, Rub�n Mart�n wrote:
> After a long discussion on mozillians list
> <https://groups.google.com/forum/?fromgroups=#%21topic/mozilla.mozillians/AA7nu8_jiYI>,
> I want to bring this topic here with a proposal:

I really like the idea for having the link in the posting to an
appropriate timezone converter, that's good, its something I've been
doing for a while.

We *can go further*.

Taking a thought from the previous thread on mozillians:

=== Begin Quote ===
I'm thinking that this is enough of a pain point to seriously consider a
calendar tool integrated into Mozillians.org, which would not only do
the time zone conversion, but also show possible conflicts to
organizers, show each Mozillian "their" meetings based on their groups.
affiliations, invitations, and explicit subscriptions, and provide an
ical feed to subscribe to, provide templates for sending out mail (and
optionally, send those out automatically to the right mailing lists),
automatically create etherpads for each meeting for the agenda and
minutes, and so on. If such a tool were easy enough to use, and tightly
integrated, it wouldn't take much work to gently steer everyone there,
at which point the problem would largely go away.
=== End Quote ===

I think that having some form of meeting organiser tool(s) that would:

a) provide calendar subscribe options
b) provide emails/newsgroup posts for regular meeting updates
(automatically generated)
c) provide wiki (or other) insertion/updates

would alleviate the issues of choosing a 'host' timezone for the
organiser, but also provider options for attendees receiving the
information to select what works best for them, and to get the right
time every time.

If the tools were all automatic, then it wouldn't matter how we
represent timezones.

Do we have tools to do this already? What would it take to go the extra
steps?

Mark.

[Majken Connor]

I agree that we don't want a super huge policy around meetings, but I think
the original proposal - always include UTC when listing/inviting people to
meetings or similar global events - makes sense and doesn't take us down
that rabbit hole.

Dealing with Reps has given me a good experience with meetings on a more
global scale (there aren't many of us in North America compared to other
regions). I think understanding how your time zone relates to UTC is a
basic and simple skill. A much simpler skill than many other we require for
contributing to Mozilla. I understand that sometimes this breaks especially
with people who aren't used to dealing with other time zones, but I think
that's a sort of entitlement argument. I haven't had to learn UTC so far
and I don't think I should have to.

We need to compare the demands we're putting on one segment of our
community - show up at the same time all the time vs potentially 4 time
changes throughout the year (remember that the US/Canada observe DST on
different dates than other countries). In the Norther Hemisphere this means
the meetings happen at 2 different times throughout the year, but doesn't
it mean that the meetings happen during at least 3 different times in the
Southern Hemisphere? While it would be nice to solve problems for
*everyone* it does seem like we're putting some parts of our community at a
much stronger disadvantage than others.

Yes, there are tools to help people and we should investigate that, too.
But can't meeting organizers also use those tools to make sure they're
listing the correct UTC? Yes, some mistakes will still be made during the
periods when DST goes in and out, that is inevitable with DST being
observed (yes you can use a calendar, but are you using alerts? and if
you're using alerts are you becoming complacent to those alerts and don't
notice the time change?). Asking for UTC times isn't supposed to be some
magic bullet. It's meant to help, and acknowledge the global nature of the
community. Also UTC is a standard. It doesn't change. It is much easier to
convert back and forth from your own timezone than it is to convert from
another timezone that may or not be observing DST while you may or may not
be observing DST.

I think it will also just be helpful all around to have a standard way to
handle this as we are getting more and more global and not all meetings are
anchored in PT anymore. I missed a meeting once because I didn't notice it
was set in ET. Some people are starting to include a bunch of common
Mozillian time zones, which has even more room for error, even with using
conversion tools. I don't think we need to get into the potential mess that
could happen when different meetings anchor in timezones that observe DST
differently, I think teams will be aware of who can make what meetings and
find a solution that is appropriate for that team (eg Reps anchor their
meetings in UTC, which works for us).

You'll also notice I am typing ET and PT, many North Americans who aren't
used to having to think in other timezones keep typing PST, which means
Pacific Standard Time, which is UTC -8, even when observing Daylight
Savings, (PDT, UTC -7). If a state doesn't observe DST it will remain in
Standard Time. You could argue that this is a good reason not to try and
make people use UTC as well, but in my experience, and I think the logic
holds, that the opposite would be true. Getting used to dealing with UTC
will help a person better understand their timezone and remember when
they're observing Daylight Savings or Standard Time. Awareness and practice
go a long way.


On Mon, May 13, 2013 at 4:39 PM, Mark Banner <mba...@mozilla.com> wrote:

> On 13/05/2013 15:43, Rubén Martín wrote:
>
>> El 13/05/13 15:14, Gervase Markham escribió:
>>
>>> By posting this here, are you saying that Mozilla should have an
>>>
>>> official policy (as opposed to, say, a best practices recommendation) on
>>> the right way to do meeting announcements? If so, I'm not sure I agree
>>> with that.
>>>
>> Uhm, probably it's a good idea to have a policy, I don't see how that
>>
>> can be a bad thing. For me is part of being global and inclusive with
>> the rest of the community using a standard way to express times and
>> facilitating the work to mozillians.
>>
>

> I believe that having a policy for everything will end up in a huge list
> of policies, that we won't manage, and that will probably tend to mean we
> all have to act the same way, irrespective our our individual cultures.
> I've no proof of this, but that's my feeling.
>
> I'd rather we look at what we can do to improve things for everyone, not
> just a section. Hence, see the post entitled "Improving our tools for
> meeting scheduling" that I'm just about to post.
>
> Mark.
>

> ______________________________**_________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/governance<https://lists.mozilla.org/listinfo/governance>
>

[Gervase Markham]

On 13/05/13 21:41, Mark Banner wrote:
> I think that having some form of meeting organiser tool(s) that would:

I've also been thinking a lot about how we can solve the problems people
are having with better tools. Not wanting to hijack Mark's thread, but
my tool idea is different :-)

timeanddate.com is OK for a single meeting, but what we really want is a
URL which encodes a meeting sequence. So the URL doesn't have to change
each week. So you would have e.g.:

http://time.mozilla.org/?t=0830&tz=America/Los_Angeles&freq=weekly&day=Wednesday&title=Foo%20Meeting

And that would take you to a page which said:


==Foo Meeting==

This event normally happens weekly on a Wednesday at 8.30am Pacific Time.

Next occurrence:

08:30 Pacific Time, Wednesday 15th May

In your timezone, [ Europe/London |V], that is:

16:30 British Summer Time, Wednesday 15th May

In UTC, that is:

15:30 UTC, Wednesday 15th May

[Add one event to calendar]
[Add sequence to calendar]


An example for an event whose fixed time was defined in UTC would be:

http://time.mozilla.org/?t=0830&tz=UTC&freq=weekly&day=Wednesday&title=Bar%20Meeting

==Bar Meeting==

This event normally happens weekly on a Wednesday at 8.30am UTC.

Next occurrence:

08:30 UTC, Wednesday 15th May

In your timezone, [ Europe/London |V], that is:

09:30 British Summer Time, Wednesday 15th May

[Add one event to calendar]
[Add sequence to calendar]

[Dirkjan Ochtman]

On Tue, May 14, 2013 at 11:45 AM, Gervase Markham <ge...@mozilla.org> wrote:
> timeanddate.com is OK for a single meeting, but what we really want is a
> URL which encodes a meeting sequence. So the URL doesn't have to change
> each week. So you would have e.g.:
>
> http://time.mozilla.org/?t=0830&tz=America/Los_Angeles&freq=weekly&day=Wednesday&title=Foo%20Meeting

Heh; I've been thinking along similar lines. Yesterday, I registered
arewemeetingyet.com. So far, it's more of a stripped down
timeanddate.com (because when I go there I get so distracted by all
the clutter that I don't quickly see what I want to know), but it
should be straightforward to extend for repeating meetings. Having a
non-UTC reference timezone is a little harder, but I somewhat know my
way around the tzdata distribution, so I can probably figure something
out.

Here's what I have so far:

http://arewemeetingyet.com/2013-05-16/19:00/Meeting%20tool%20test

(The URL is the interface for now.)

Cheers,

Dirkjan

[Gervase Markham]

On 14/05/13 13:14, Dirkjan Ochtman wrote:
> Heh; I've been thinking along similar lines. Yesterday, I registered
> arewemeetingyet.com. So far, it's more of a stripped down
> timeanddate.com (because when I go there I get so distracted by all
> the clutter that I don't quickly see what I want to know), but it
> should be straightforward to extend for repeating meetings. Having a
> non-UTC reference timezone is a little harder, but I somewhat know my
> way around the tzdata distribution, so I can probably figure something
> out.
>
> Here's what I have so far:
>
> http://arewemeetingyet.com/2013-05-16/19:00/Meeting%20tool%20test
>
> (The URL is the interface for now.)

Thanks for doing this! I have a lot of feedback and design ideas to suggest.

mozilla.governance is not the right place to design this - should we go
over to mozilla.tools?

Gerv

[strazd...@gmail.com]

I always simply ignore all meeting proposals that do not include UTC. it is called universal time zone for a reason. if you post your time in "my island time" im not going to bother trying to figure out how many hours should i add and theres a participant lost already.
There is a slight problem with DST, however that will go away soon as there were extensive studies showing that it is actually harmful, outdated thing that is held on to for absolutely no reason but tradition. IT saves us 0.003% of our energy spending and causes 30% increase in mental disorders. im not willing to make that trade are you?
However counting in the DST is much easier than deciding to account for somones local time changes AND DST in BOTH LOCATIONS.

[Erik Rose]

Having just changed residences from "Mountain View Standard Time" to Eastern time and then immediately flown to India, I also favor UTC. In an ideal universe, we'd use Zulu, which doesn't observe DST, but I think that will have to wait for the areas where most Mozillians live to jettison DST, lest we disrupt everyone's routines twice a year. So +1 UTC. :-)

[Erik Rose]

> I also favor UTC. In an ideal universe, we'd use Zulu, which doesn't observe DST

Ah, UTC === Zulu, neither observing DST. Color me informed. :-)