I am trying to set up a time and date to schedule an appointment, so I collect the date first and verify that times are available on that date. Then I try to collect a time for that date, if that time does not exist I want the customer to be able to ask something like, "How about Friday at 6pm." and it will change the date. Is there an easy way or workaround to get this functionality?
Related
Looking through the graph api and I can list appointments with the start time and end time in the calendars time-zone.
Can I find the calendar's time-zone without looking at an existing appointment? I would expect it to be in the bookingBusinesses/{id} resource.
We have several calendars in several timezones and working through an algorithm to figure out available timeslots. Obviously "Day 0" is the worst - no appointment = no timezone data. We can work around it by creating one appointment. Is there a better way though?
You cannot fetch the time zone of the Calendar however you can fetch the time zone of User mailbox that owns the Calendars. AFAIK calendars don't even have their own independent time zone settings but refer the parent user mailbox's time zone setting.
The User.mailboxSettings API can be used to fetch timezone preference of the Calendar
curl -X GET 'https://graph.microsoft.com/v1.0/users/john.smith#contoso.com/mailboxSettings/timeZone'
Here is the official documentation.
https://learn.microsoft.com/en-us/graph/api/resources/mailboxsettings?view=graph-rest-1.0
It is worth noting that the timezone values format follows Windows Timezones. Your programming platform may not be following the same and might be using IANA timezone format, then you would need to translate windows timezone to IANA timezone
Hey I have a rails application and a bunch of users and I want to send them a message once per day at a preferred local time of the user's choice. (A message is a text, email, or chatbot notification.)
I believe I could add something to my User model that would allow for something to be performed every 24 hours at the preferred time but I'm not sure specifically how to implement that AND I also don't know how to remove these jobs from the queue if, for example, the user changes their preferred time or they want to disable messages all together.
Any thoughts on how I could do this?
Where is your application hosted?
You can have a cron task or a scheduler (Heroku) that runs every hour (or every 10 minutes). It would query in a users preferences table searching for users who want to receive the email at this moment (or in a range near this moment, such as the next 10 minutes).
time = Time.now
#users = User.include(:settings).where(“settings.receive_email_at between ? and ?”, time, time + 10.minutes)
You may need some changes to handle timezones and to avoid sending duplicate emails, but that’s just an idea.
It's simple. Build two models - One to store user and its time mapping (UserTimeMapping) and the second one to create a unique entry for each day when a message is sent to user (UserMessage).
Write a cron task which runs every 10 minutes and pulls all the records from UserTimeMapping which are to be executed for next 10 minutes and schedules a worker task for the exact time (say MessageTriggerWorker). The worker has to check in UserMessage table whether a record exists for the given user_id for today and if yes it has to return without performing any task. If that is not the case then it should send the message and create a record in the UserMessage table.
In my app, users can select a time that they want to receive a daily email. I then regularly run a script to find users who have an upcoming email to send and send it. So, if users elect to have an email that goes out at 7AM, I look for users with that selected as their time and send it.
The problem is of course timezones. I'm going to have users in different timezones and need 7AM to always be 7AM, regardless of timezones or daylight savings.
I can understand how to do it for display purposes, but I can't find much info on executing queries that have to factor in the timezone and DST for a collection of users with varying times and timezones.
This can probably be most easily accomplished by simply saving everything in the database as UTC. You can adjust the times for display and incoming form data by using the users' specified time zone.
Is there a way to create a SharePoint 2007 calendar that only allows users to input appointments in certain time slots? I would like the time slots to run Monday thru Friday from 8am - 10am, 10am - 12pm, 1pm - 3pm, 3pm - 5pm, and 5pm - 7pm. Only one person can sign up in a time slot at a time.
I do not want to have to enter every date from now till the end of time, which is the how this solution works: http://sharepointsolutions.blogspot.com/2009/02/give-blood-to-your-workflow.html
That is a great solution for the one-time Blood Drive type of time slotting but not exactly what I need.
I would either :
adapt the new form or create a custom one that will prevent people from adding a new event outside of your specified time slots and ensure that a specific time slot is not registered by someone else prior to save it. That will allow you to create a dedicated UI with relevant controls (eg : dropdown lists that have only the hours that you specified)
add an event handler on ItemUpdating that will ensure that there is no collision with another event and validate your business requirement regarding time slot. You can then transfer to an error page with a proper explanation message
Both solutions require custom development. I would be glad to hear if there is something out of the box that would fulfill this need.
I'm working on a Rails application that's kind of like a blog. Users create Entries. I'm trying to work out how to handle time storage and display. I've read this writeup about Rails timezone support.
It's great but it doesn't cover what my app needs to do. It only looks at cases where you want to convert stored time to the current logged in user's time zone. In contrast, the effect I want is...
A user creates an entry in California at 10:00 a.m.
A couple years later he moves to New York and then at some point looks at his old entry. The "created" date should say "10:00 a.m." He doesn't care about time zones. He just wants to know what time of day he felt like it was when he wrote the entry.
If he then edits the Entry in New York the displayed "modified" date is, again, his subjective time of day when he made the edit. (Let's assume he went to "preferences" and changed his time zone setting when he moved.)
Also, for the sake of thoroughness, the app should be able to report the "real" absolute time when an Entry was created or updated.
(Note -- my imaginary user is a guy, but for women it should work roughly the same way.)
The way I'm thinking of implementing it is...
Have the attributes User#time_zone, Entry#created_at_utc, and Entry#updated_at_utc in addition to the standard created_at and updated_at.
The user selects their time zone from a menu when they sign up. (They can change it later if they want.)
The app uses User#time_zone to store created_at and updated_at in the user's subjective local time. If it's 10:00 a.m. for them, the app writes "10:00 a.m." to the DB.
The app also saves the current UTC time in the aforementioned _utc fields to deal with the last requirement above.
Is that a good way to do it? Is there a better way?
The two roads you can take are:
Store a timezone (UTC) in the user account as well as in every post - update the post's timezone along with the updated_at field whenever the user changes the post (if he or she has changed timezones).
Store the timezone only in the user account. When the user changes timezones, update every post that belongs to the user and add/subtract to the created_at/updated_at dates.
The first option seems like the cleanest option to take. For this you would only have to create a new method in your post record:
def locational_updated_at
updated_at + timezone.seconds
end
Where timezone is an integer containing the seconds since UTC.
If you can, you should avoid storing two different sets of timestamps, and you should avoid storing any non-UTC dates. Both of these things will lead to confusion. I'm not completely sure I understand what you're doing (though I like your idea of subjective time), but wouldn't it be enough to just attach a time zone to every post, and always use that zone to display the times? It would default to the time zone set in the author's account, so he could change it when he moved cross-country without affecting previous posts.
I think that's all you need--to attach a time zone to every post. Is that sufficient? Or am I missing some part of this?