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

Robot Availability #41

Open
GraysonHoward opened this issue Jun 12, 2018 · 3 comments
Open

Robot Availability #41

GraysonHoward opened this issue Jun 12, 2018 · 3 comments
Labels
High Priority Very important, should be prioritized. question Further information is requested

Comments

@GraysonHoward
Copy link
Collaborator

From the meeting last Friday I learned that Aleks wants the robot available in time slots in 30 minute increments from 8-5 no weekends. Holidays are a special case and will be manually rejected. We may want a way to post notices to the schedule page saying what days the robot will be unavailable like if everyone will be gone for a break or something of that nature.

@GraysonHoward
Copy link
Collaborator Author

Another thing I don't think we've addressed is the DST and how it will effect things. The US is one of few places that still use it. Not sure how that will change things. Date.toLocaleTimeString() and Date.toLocaleString() will translate times and dates respectively to whatever the local standard is which may be useful.

@BinaryFissionGames
Copy link
Collaborator

So, there are 2 ways we could deal with this.

  1. We could hard code the times we want (just place them in code, basically just checking against GMT times to see if a particular time is good or not)
  2. We could have the server send which times are acceptable in GMT, which could then be checked by the client.

I think we should start by implementing 1, by creating a function that checks if a certain time is acceptable (takes in a Date object, returns a Boolean) and that would make it easy to move to 2 later.

Let's ignore DST for a little bit until we start to implement 2, because that's where it will REALLY matter. I think.

DST doesn't matter client-side (at least in America) if our times are 9-5, because DST takes place at 2/3am or something like that, which is out of that time range. Using the date object should automatically take care of any other problem for us.

Speaking of which, the Date objects representation is mainly dependent on time zone of whoevers running it. So the getHours method will return the hour of the client if run on the client machine. To check against GMT, which is what we want, we should use Date.getUTCHours and Date.getUTCMinutes.

@GraysonHoward
Copy link
Collaborator Author

Question to bring up to Aleks would be how far out he wants people to be able to schedule, we could potentially paginate the sing up to allow for this.

@BinaryFissionGames BinaryFissionGames added High Priority Very important, should be prioritized. question Further information is requested labels Jun 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
High Priority Very important, should be prioritized. question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants