Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish minutes of 2021-07-22 meeting #46

Merged
merged 1 commit into from
Jul 30, 2021
Merged

Publish minutes of 2021-07-22 meeting #46

merged 1 commit into from
Jul 30, 2021

Conversation

Rob--W
Copy link
Member

@Rob--W Rob--W commented Jul 23, 2021

Generated from https://docs.google.com/document/d/1QkwhEMtMS67JBUkl_WVPZ4lRSKoWcQNlLJSf_GwSXg8/edit

Using a process similar to #23.

During this meeting, we discussed or mentioned #13, #30, #36, and agreed to file new issues (about tracking work on manifest file (TBD) and participating in TPAC at #45).

@Rob--W
Copy link
Member Author

Rob--W commented Jul 23, 2021

So far I used the PDT timezone as the primary point of reference (with UTC and time zone converters). Should we continue to do that in this way, or should we start using UTC instead? If we use UTC, then the document should be attributed to 2021-07-23 instead of 2021-07-22.

@mukul-p
Copy link
Collaborator

mukul-p commented Jul 23, 2021

So far I used the PDT timezone as the primary point of reference (with UTC and time zone converters). Should we continue to do that in this way, or should we start using UTC instead? If we use UTC, then the document should be attributed to 2021-07-23 instead of 2021-07-22.

UTC would be better choice. We can check what is the precedent.

@dotproto
Copy link
Member

As I recall, when we last discussed time zones we decided to use Pacific time because the browser member reps either worked in or worked closely with people in that time zone. Targeting the Pacific time zone allowed us to set a single time (8 AM Pacific) without regard for daylight savings time.

If we were to use UTC, we would need to decide how to handle daylight savings: do we keep maintain a fixed UTC time or adjust the meeting to accommodate daylight savings? If so, what DST region do we accommodate (observation dates vary by location)?

@Rob--W
Copy link
Member Author

Rob--W commented Jul 26, 2021

I'm fine with using PDT as a reference (since we based our meeting schedule on it, and conversions to other time zones are provided in the schedule and meeting notes).

@mukul-p Any objections?

@dotproto
Copy link
Member

Ah, I was thinking more about how we schedule rather than canonical datetime references. My personal preference would be to schedule around Pacific but for fixed dates and times to use UTC. @xeenon, do you have any thoughts?

Copy link
Member

@dotproto dotproto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I'm good with either holding off on this merge until we resolve the UTC question or accepting it as is and updating the timestamp later if necessary.

@dotproto dotproto merged commit 3894d1b into main Jul 30, 2021
@dotproto dotproto deleted the meeting-2021-07-22 branch September 2, 2021 18:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants