I want to create a a calendar like google calendar to keep track of people's upcoming events.
The problem is that people can have recurring events. Events that occur every week or every 2 days or every 1 month etc or every 4 weeks
But I want to be able to list upcoming events...
How do I do that using php and mysql?
For example if an event that occurs once every week from 10/31 to 11/30, do I have to create a separate row in the database for each week?
But what if the event occurs every weekday from 10/31 until forever?
I just want people to add events into the database, and then list upcoming events that they have coming up.
I also want to have a cron job that reminds people of upcoming events.
If I have a cron job - if I store each event once (for example an event that occurs once every 2 days, I store it as one row in the database describing that it occurs once every two days), then I would have to do a lot of calculations each time I run the cron job to figure out whether the event occurs today (considering it is is supposed to occur once every 2 days, I need to calculate if today is one of those days that it occurs).
Is there an easier way to approach this?
I let people set the following recurring properties:
event occurs every X number days, X number weeks, X number months,
event occurs every weekday from DATE to DATE, or from DATE to forever
event occurs every month, week, every Mon Wed Fri, or every Tues Thurs
Related
I have a specific date like 2021-01-07 from when some event should start. After starting, system should send notification daily or weekly or even monthly based on the values chosen by the user. So how can i calculate the daily/weekly/monthly date to send notice every month?
I tried using time offset like this:
event starting date + 7 days (for weekly)
event starting date + 3 weeks (for month) so on
but this only works for the month for starting date not for future months.
This notification functionalities is triggered when some event occurs on the site. can not use cronjob task statically.
I want to create a website with an scheduling calendar.
My first idea is to use some free calendar template or download some free scheduling calendar. Then in my scheduling form, when someone request for an schedule, I will get the date he/she input and save it into the database then show it to the scheduling calendar.
But someone told me that, in my database, I should create a calendar table.
Which is the best way around?
The first one with only one table for schedule on my database or the second one with two tables for schedule and calendar?
I hope you get my idea.
It could be first one. One of option is to keep data by day of year.
you can draw your own calendar by counting day of year
actual day of yaer - date('z') + 1; //+ 1 because it is an array it starts from 0
then you can get number of days in each month
cal_days_in_month
and loop it x 12 with
here will be day of month with css style so it looks like calendar field
your i++ will bee number of days in month of course.
Keep records in database by year and day of year. you can do so much things this way
Essentially, what I need is the ability to tell what week day is coming next by the user selected week day, month & month day. It's for a cron job (I'm using both standard and page loading cron jobs for my portable application. They'll both be ran the same way (apart from so in the admin panel the user will have the ability to see the next scheduled run of task X)
Everything is working perfectly so far without the week day. But I have no idea how to implement this. I need a system where the user will select, say, the month 'January', the week day 'Saturday' and month day '13', even if it's two, three .etc years in the future. Or even just the first two of those. From this, I need to set the next scheduled run of the task. There are still a few undefined variables .etc, but I'm in the process of tidying it up a bit.
Here is what I have so far:
Any help would be appreciated.
I'm trying to create a schedule of unique, recurring events that cycle on a weekly basis (each event will have unique identifiers and repeat weekly).
In addition to other information gathered about each event, I will gather the weekday on which each event will take place and the dates (calendar dates) on which the event will begin and end.
An example:
Event: Go to gym (the event I plan to do once a week)
Day of Week: Sunday (day of week event will occur (every Sunday))
Start Date: 2014-09-01 (happens to be a Monday)
End Date: 2015-08-31 (...)
The purpose is to write a script that takes any multitude of events and their respective weekday/start/end date and recreate a calendar depicting the future calendar dates on which each event will occur.
So the first date I should see scheduled to go to the gym will be:
2014-09-07
because this is first Sunday following the start date.
To sum it up, I am gathering the weekday of each event as well as the start and end dates. How can I parse these pieces of data into something that spits out a list of the events' future dates of reoccurrence?
Keep in mind that there will be a vast number of events that will occur on different days of the week and have different start/end dates.
Thank you for all who read and respond.
Tried:
SQL: grouping, different select statements, and stuff
PHP: stuff, date/time stuff, and stuff stuff
For next event in schedule you could use strtotime function:
strtotime('2014-09-01 next Sunday');
and use returned UNIX time.
But for complete solution of your problem there can be many ways. IMHO, strtotime used in for cycle can give you a large overhead if calculated on demand. If you store schedule in DB, perhaps it will be easiest solution to generete dates and regenerate them on edit.
In other hand, dates are pain in head so algoritm to calculate all ocasions can be much bigger. You can use intervals calculated from difference of result date from first date if $firstDate = $startDate or if event happens every day once a week, then just add 7 days to it.
Post more details or your solution to find mistakes.
I want to create a php calender application. What is the optimal database design for this software if I want to create normal, weekly, monthly and yearly events.
I would just create an entry for each recurrence of the event, out to some horizon. However, it means that you'll need another table that you can use to project out the dates if they scan past your horizon date. I.e., you'll need an events table that contains one record for each occurrence of a repeated event (Jan 1, Jan 8, Jan 15, ... through December), and a table with each record available to seed future years (start date: Jan 1; repeat: 7; through: 2011) so that at the start of 2012 (or as soon as the user requests a view of a 2012+ month) you can generate the future events.
This has two big disadvantages:
Your database has data for a full year. However, if adding a full year's worth of data ruins your performance, your system is probably underpowered. (It seems a requirement that a calendar app be able to handle many years' worth of dates)
At the end of the event horizon, you need to generate the future dates for recurring events.
The advantages (IMO) that outweigh the disadvantages:
Easier math when displaying the calendar. Using Tim's method, above, if the user loads Dec 18, 2011, how are you going to calculate which recurring events should be placed on that day? You'll be forced to loop through EVERY recurring event every time you display a date. The tradeoff is disadvantage #1, which I think is the better solution that having to redo these calculations.
You can edit specific instances of an event. Using Tim's method, if a meeting occurred on a holiday and the user changed it to the previous day, how would you even do it? Using the one-entry-per-event method described here, you could just modify that record for the event, easily moving single occurrences around in the calendar.
You could have a column in the EVENT table for RECURRENCE_STATUS which tracks 4 values, does not recur, weekly, monthly, yearly. The query of the day's events would be a union of those that are set to occur on that day and which do not recur with the set of those that do recur and whose initial date's difference from today is a modulo 0 for week, month, and a year differences. The date-math calculations are a little more nuanced than that (because of the varying number of days in the month) but the structure should suffice.