I'm trying to set up a way to be able to step backward and forward through sets of time ranges.
I'm creating a simple display for my work's production floor. Every time a user scans a barcode a serial number is generated in our ERP system. In order to track progress throughout the day they want a display that will show how many serials (and because of that, how many widgets) were processed that day. The display would also show the previous shift's widgets. So at any given time you look at the display you'll see the current shift's progress, and then the previous shift's totals.
We run 3 normal shifts throughout the week. 1st shift 6am to 2pm, 2nd shift 2pm to 10pm, 3rd shift 10pm to 6am. Then on both weekend days we have a weekend shift that runs 6am to 6pm.
I currently have a spaghetti noodle mess of if/else statements that make this actually work, but I really want to clean it up and make it easier to maintain long-term.
So let's say it's Monday 1st shift. I want to grab Monday 1st shift's totals, but I also want to step backwards by 1 shift to the weekend shift and grab those totals to display. The weekend shifts are really what threw this for a loop because now I have to be aware of the day of the week. 3rd shift is a little leery as well because it crosses over into multiple dates. Is there a clean way to set this up? A library out there that lets me define these things easily?
Hope this made sense. Happy to clarify anything I'm missing. Thanks in advance for any guidance!
Maybe a shifts resource would be usefull.
creating a shifts table with id, start_date, end_date, shift_type,...
when scanning for a barcode:
if the current shift was already created, assign a shift_id to the barcode row
if not, create the shift row, and assign a shift_id to the barcode row
Benefits:
Very easy and fast query to get the results that you need
If shifts changes (starting hour, ending hour,...) it would still work (the only change needed is on the method that creates the shift row)
Comparing shifts results would be very easy
Have you tried using CarbonPeriod? Note that Carbon is already included in Laravel so there's no need to go and add it with Composer.
Related
I am working on a school project where I am keeping track of a user's tweeting frequency per week. I have working code, but at the end of each 1-week period, I need to manually adjust the new starting tweet total and the date of one week in the future.
How can I automate it so the final tweet count becomes the new starting tweet count, and one week gets added to the ending date? Am I heading in the right direction with the code below, or should I be storing these final tweet total values in a database? Thank you!
// Get current tweet total and calculate current count
$ptTotal = $ptObject->{'statuses_count'};
$ptStart = 572;
$ptCount = ($ptTotal-$ptStart);
// Set end date & convert to EST
$ptdatestr="2017-05-30 12:00:00";
$ptdate=strtotime($ptdatestr)+14400;
// Calculate time remaining
$ptdiff=$ptdate-time();
$ptdays=floor($ptdiff/86400);
$pthours=round(($ptdiff-$ptdays*86400)/3600);
// Re-set start value and add one week to countdown
if ($ptdiff <= 0) {
$ptStart = $ptTotal;
$ptdate = $ptDate + 604800;
}
I say regardless of how you are automating this code block (see Alejandro's comment), you should move away from using any approach that includes +86400 (or a factor of). Things will go BONK in the night when daylight savings is involved.
Instead, I recommend that you integrate DateTime objects. They are highly versatile and have specific features that will aid you in your specific project. This is a full list of related functions: http://php.net/manual/en/book.datetime.php
Implementing Datetime objects and functions will make your project solid and lean. Immerse yourself in the above php manual pages and the comments that follow; and continue to research on StackOverflow.
More to your specific questions: Yes, I think you are on the right path. Yes, I think I'd store the data in a database.
Good luck.
I am creating a system that requires a schedular for a particular task. Users may pick from times 24 hours a day, 7 days a week.
I came up with a few options for the database storage, but I don't think either one is the most efficient design, so I'm hoping for some possible alternatives that may be more efficient.
On the user side I created a grid of buttons with 2 loops to create the days, and the times, and I set each a unique value of $timeValue = "d".$j."-t".$i;
So d1-t0 will be Saturday at Midnight d3-t12= Tuesday at Noon, and so forth.
So, in the database I was first going to simply have a ID, day, time set up, but that would result in a possible 168 rows per event
Then I tried an ID, day, and time 0-23 (a column for each hour of the day) And I was simply going to have a boolean set up. 0 if not selected, 1 if it is.
This would result in 7 rows per event, but I think querying that data might be a pain.
I need to perform a few functions on this data. On each day, list the number of selected times into an array. But I don't believe having a select statement of SELECT * from schedule where time0, =1 or time1= 1 .... ect will work, nor will it produce the desired array. (times=(0,3,5,6,7...)
So, this isnt going to work well.
My overall system will need to also know every event that has each time selected for a mass posting.
"Select * from table where time = $time (0-23) and day= $day (1-7)
Do action with data...
So with this requirement, I'm going to assume that storing the times as an array within the database is likely not the most efficient way either.
So am I stuck with needing up to 168 rows of data per event, or is there a better way I am missing? Thanks
Update:
To give a little more clarity on what I need to accomplish:
Users will be creating event campaigns in which other users can bid on various time slots for something to happen. There will likely be 10-100 thousand of these campaigns at any one time and they are ongoing until the creator stops them. The campaign creators can define the time slots available for their campaign.
At the designated time each day the system will find every campaign that has an event scheduled and perform the event.
So the first requirement is to know which time slots are available for the campaign, and then I need the system to quickly identify campaigns that have an event on each hour and day and perform it automatically.
I am building a Time Clock application with PHP and Laravel 4.
My boss requires that he is able to pull and build different reports based on the data I store in the database for a Time Card record.
Right now I store a DateTime for clock in and clock out as well as a Timestamp for both those times as well into the Database.
I need to be able to Query the database and build reports for different Pay Periods for a user.
So for example I will store in another Database Table, records that will be for a User ID and will have different Pay Periods. So a Start day may be the 1st of the month and end date the 15th and that is 1 pay period (roughly 2 weeks) I am not sure the best way to store these records really.
Another will be the 16th of the month to the end of the month. So the end date would be different depending on how many days are in a month
I am not sure about the best way to define these Pay periods for a user. I can't simply say 1-15 and then 16-30 since the 30 would be a different number for each month.
Would appreciate any insight into how this could be done?
So I can build reports for any Pay Periods since not every user gets paid every 2 weeks it needs to be flexible so that I can define it on a per user basis
This question is more about the Logic instead of actual code.
Welcome to the wonderful world of Time and Attendance. You are touching the tip of the iceberg. You may find that purchasing a pre-packaged product may be easier than writing your own.
That said, I can offer you the following general advice:
Be very careful of your data types and how they are used, both in PHP and in MySQL.
You need to make sure you understand local time vs UTC, time zones, and daylight saving time. In general, you don't want to store local time unless you also store its offset from UTC. Otherwise you will have ambiguity around daylight saving time changes. This is important even if you only have one time zone to deal with.
When it comes to Pay Periods, the common types are:
Weekly
Bi-Weekly
Semi-Monthly
Monthly
Every X days starting from Y
In some systems, each individual pay period can be adjusted +/- a number of days from it's normal date. When doing so, the bordering period must also be adjusted to compensate.
You should start with business logic that can calculate the start and end date for a pay period given any particular date and time. You can then expand that to easily get the prior or next pay period.
You can store each pay period into it's own table, but it's not necessarily required. That will depend on a lot of specifics about your system internals.
Because a pay period is defined by dates, you have the "Whose Day is it?" problem. It might be the day as defined by the company, or if employees are in different time zones, then it might be the "logical day". If you only have one time zone to deal with then, you are lucky in this regard.
When comparing against the pay period, use half-open intervals, [start, end). In other words:
periodStart <= punchTime < periodEnd
or likewise
periodStart <= punchTime && periodEnd > punchTime
The end of one period should be exactly the same as the start of the next. Don't try to define the end of the period at some silly value like 23:59:59.999...
As you can see, this is just the beginning. I hope this is useful to you. If you can narrow the focus of your question further, I'll be happy to help more. Otherwise, it's like asking for how to build an ERP system when you're not sure what structure to store inventory.
I think you are over thinking this. Let thte user define the start and end dates.
You will need the UserId, a timestamp (time in and time out) of the user and that should be about it.
I picture something like this:
UserId | DateIn | DateOut
On the page you could put put dropdowns (or if you want a nifty interface a datepicker that uses javascript) and allow the manager to pick a start and end date that he wants to choose.
So if he wants to see an employees time between Jan. 1 and Feb. 31 he can choose those as his start and end dates.
This will allow things to be very flexible, for example the manager can choose Feb 16 as start date and Feb 29 as end date. It makes sense to allow him to choose the data requirements so he can view whatever he wants.
EDIT:
An example from my comment below this post you could do something like:
$startDate = new DateTime();
$startDate->modify('first day of this month'); //or 16th for second part of bi-monthly
$startDate->format(#some date formatting as you need#);
$endDate = new DateTime();
$endDate->modify('last day of this month'); //or 15th for first part of bi-monthly
$endDate->format(#some date formatting as you need#);
If things are even less defined however you could always try doing special math. date('t') will give you the number of days in a month. I would refrain from using this unless your pay days are fixed such as paid every 6 days.
In general I would harness the power of the PHP DateTime class over using date() function. http://php.net/manual/en/class.datetime.php
I have a website where people record (or log) the distance of their runs. I want to create a leader board that will automatically reset to zero after the month is over. If I could save their total distance for that month as well, that would be ideal. Every run is tied to IDs and I have a variable that adds up the monthly distance, but obviously when they log a new run that changes. I don't know how I would make it record this month only and not freak out if they log in advance.
Any help would be appreciated.
I have tried making a monthly distance value for MySQL so each time they log, if it is that month, it will add to it. But how should I make it reset?
You're tracking the date of each run, right? Then you should be able to do something like this and avoid having to store the totals:
SELECT SUM(Runs.Miles) as MonthlyTotal
FROM Runs
where MONTH(Runs.Date) = MONTH(CURDATE()) and YEAR(Runs.Date) = YEAR(CURDATE())
(Presumably you'd also filter by or group by the UserID. Also, I suspect it may be more efficient to pre-calculate the beginning and end of the month and use BETWEEN in the where clause. Consult our friend EXPLAIN.)
If your read load is too high to make this practical, you could store the monthly total in a different table and update it with a trigger every time a run is added or updated, and via cron at the start of every month. This kind of de-normalization always makes things more complicated, so I avoid it until I have reason to believe it's necessary.
I have a database that holds events in the following format:
Schedules
id
show_id
starttime - datetime
endtime - datetime
repeatuntil - datetime
repeat - int
nthdayofmonth - int
repeatmultiple - int
show_id holds the ID number for the show which is stored.
Shows can be stored multiple times for different recurring, or different days/time variations.
startime, endtime, and repeatuntil are bit obvious as to what they do.
repeat is the type of repeat :
1 - hourly
2 - daily
3 - weekly
4 - monthly
5 - yearly
nthdayofmonth am not 100% whether this is needed or will be used
repeatmultiple is to be used when the events are wanted to be repeated every other week or every other month so on...
What I have been struggling with is the code that calculates when the next event occurs, I have tried various solutions from the internet and stackoverflow but am still struggling. Majority of the time my code ends up in an infinite loop and is unable to work out the correct date for the next event.
If someone is able to help out with the coding of a function that can loop through finding the next time an event occurs I will much appreciate there assistances as I am getting very frustrated and not much further from when I started.
I think you can approach this by characterizing the two functionalities that you really need here.
First, you need a method of calculating the next DateTime that a given Show will execute. This is irrespective of any other Show, and has nothing to do with what will come first. You need a method that, given the starttime, endtime, etc criteria, will calculate the next time that this Show will execute.
Once you are able to determine when any given Show will execute, you can move on to determining which Show will execute next. You could loop through the database, calculating Next times and storing the soonest...or even serialize the Next DateTime for each Show, and query the database for the smallest.