-
Notifications
You must be signed in to change notification settings - Fork 37
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
Fix test get meeting participants #110
Fix test get meeting participants #110
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good so far, if I understand this correctly. We're getting the subscription's timezone (America/Los Angeles) and then converting the meeting's datetime from utc to local using this timezone. Since America/Los Angeles is UTC offset agnostic, this will work correctly.
This will give us the local time of the meeting. What's the plan to localize this to individual users? That is, once we decide that 2018-01-04 13:00 America/Los Angeles is when we want meeting, how do we handle changing to local time for a participant who is in Phoenix?
I wish NDB had a Time property (timezone agnostic property), but it doesn't. I am dropping all of the Date data for the field: Subscription DateTime = 1/2/2017 13:00 <--Date is dropped along with any timezone information, we just pull out 13:00 When we move to Meeting Datetime we create a new datetime, set the time to 13:00 and apply the timezone which looks like this on 2/2/2018: Meeting datetime 2/2/2018 13:00 PDT Because a timezone hasn't been set on the new date, the .localize function just tags on the PDT without modifying the original time stored in the database. This is a bit confusing as time's that are stored for subscriptions are different than times stored for meetings, but it is the only way that I can get the right time throughout the year. This is stored in the database in UTC so if we wanted to handle local time, we can transform from the UTC value stored in the DB. |
@kentwills Refresh my memory here but I think this is going to cause issues. This is a table that shows the three actors: meeting subscription, yelp beans user 1 in America/Los Angeles, and yelp beans user 2 in America/Phoenix.
How does the logic work out against this use case? I've assumed meeting time as UTC because that's the "base" timezone from you localize to each user's specific timezone. Can we add tz info to the datastore as a new text? This will allow us to use UTC everywhere and have timezone information that can be used for localizing time just before presentation (email or preference page). |
This example provided oversimplifies the situation. There is a Meeting Subscription Datetime - this represents the time we want to have the meeting when we create a new one it is stored in UTC in the database, but when it is retrieved, it is timezone agnostic. Given the situation (with a Meeting Subscription Datetime of 21:00) above, we would instead see this:
Does this make sense? Does this use of the localize function create confusion? |
Apologies for the confusion and back-and-forth. The changes are very straightforward, after reading the |
Noted Pre-commit failure on master branch, but not reproducible on local or personal travis account.
Will follow up with a fix if the error continues. |
fixes #64.
@ipwnponies I don't think we have you as a reviewer, but could you take a quick look at this timezone fix.
I verified the emails:
![screen shot 2018-01-01 at 5 16 44 pm](https://user-images.githubusercontent.com/2310975/34472443-9406d342-ef17-11e7-9d49-a65f5318e642.png)
I verified the frontend:
![screen shot 2018-01-01 at 5 17 38 pm](https://user-images.githubusercontent.com/2310975/34472450-b6c8d650-ef17-11e7-85fa-d7f8e3521484.png)
Additionally I added/fixed tests.