I have never collected DOB before. This is the first time i am doing it.
What is the best way to first of all collect dob from the php form?
Do i allow them to enter it as 12/03/1979 or something like 12031979.
And do i need 3 fields in the db like month, day, and year?
And then for the db, what do i select for the type, date? I want to be able to reuse this data for research purposes later.
Thanks a bunch!
Do you mean Date of Birth?
You will use DATE as datatype.
For the GUI, I suggest using three dropdown boxes: Year, Month and Day. Use 4 digits for years and month names (rather than numbers) to make it crystal clear.
Under no circumstances let the user enter a date in a text field, because you won't be able to parse it correctly afterwards.
Related
The user is able to enter the amount of rain collected each day, by entering the amount of rain collected, and date. They should be able to enter rain collected in the past as well (by giving another date if needed).
So, how can i check (by using the created_at row) if the user has already entered some data for the current date? And if they have, update the value given for the specific date. I already know how to update etc, I just need a way to validate the date given.
I was trying to figure something out by using Carbon, But my head is about to explode, I can't seem to wrap my mind around this issue.
'created_at','>=',Carbon::today())
I know that wont work. The created_at looks like this:
2014-07-16 20:42:38
So I would need a way to check the current date, and skip the time/clock? How would my approach be on this?
Create your condition in query like below, to match only date in yyyy-mm-dd, to check the current date.
->whereDate('created_at','=',Carbon::today()->format("Y-m-d") )
Carbon::now()->toDateTimeString();
See how you can work with dates
How to update age automatically based on its DOB? I'm planning to write a script that fetch DOB column then calculate the age and update it. I started my idea but it still doesn't meet my objective.
Pls. help! Thanks in advance :)
Adding an age column when you have already date of birth, is slightly futile. Also, this means you would need to update the value once a year for every record, and at their birth date. That will start to get heavier and heavier. A lot of comments suggested to do the calculation of the age in PHP, this also would get heavy if you wanted to group people by age, you'd have to grab every records of the database and calculate their age. My suggestion is to use MySQL to calculate it, so you can use it in joins, where clauses, group bys and so on...
SELECT YEAR(NOW()) - YEAR(birthdate) - (DATE_FORMAT(NOW(), '%m%d') < DATE_FORMAT(birthdate, '%m%d')) as age FROM table
For more details, this was taken from How to get the difference in years from two different dates? which accounts for leap years.
You could easily create a MySQL function, call it calc_age or something and pass it the birthdate, that would return the current age and would be very easy to use...
I'm in the planning stages of creating a historical database. I will be using PHP, MYSQL and JavaScript for the website.
Often someone will know what year a person was born or picture was taken, but not the month or the day.
Is it possible for a PHP DATE variable and MYSQL DATE to be:
1920-00-00 or 1845-12-00 ?
If not, unless someone has a better idea, I'll have to create a column for year, another column for month, and yet another for day then do a bunch of value checking and combining.
Thoughts?
Thanks.
You need exakt dates for using date in mysql, so you probably have to bite down and filter everything for validating and then some code to combine it.
I have mysql database, with birthdate column as date.
What would be the best way to save into this column, with optional year. Should I just put some random year on it? what is the best practice to save birthday in database.
I create 3 text field in cakephp, day, month, and year.. but not sure how to approach this, to save in database, since if I randomly put the year (maybe 0001, since 0000 is not accepted), when I pull it back, it will show the year.
Just an opinion, but if the year is optional (some will have it; some won't) I'd use a DATE type and set the year to zero. You can check for birthdays without years like this:
SELECT * FROM myTable WHERE YEAR(birthdate) = 0
Or if the birthdate column is indexed use this instead because it'll be optimizable:
SELECT * FROM myTable WHERE birthdate <= '0000-12-31'
If the year is forbidden for all values - in other words you'll never store the year - I'd recommend separate month and day columns.
Might it be best to use three columns, Day, Month, and Year, and treat Year as optional?
Edit: Although using two might be cleaner. one DATE column and just put a dummy year in (0000) and one YEAR column. Then assemble the two as you use them. That way you get all the formatting, sorting and data validation that the data types provide, but you can still ignore the year when you don't have it
The best approach is to have two fields:
birthdate which is a date
BirthdayHasYear which is a flag (such as a tinyint)
The reason for not depending on a rule like "when the year is zero then it is unknown" is that the data structure is very hard to understand -- in the future or if someone else looks at it. I would then be inclined to add a constraint that said "if BirthDayHasYear is true then the year on birthdate is 0 (or whatever).
Alternatively, I would have one field of birthdate and then only access the table through a view where such fields as:
BirthdayHasYear
Age
are defined as additional fields in the view. In other databases, I would use this approach with computed columns.
In my application I'm developing a functionality for creating "reminders".
A reminder has a date and a time. In my application, I have a form to create / edit reminders - this has two separate fields to input this information:
<input type="text" name="date"></input> <!-- datepicker plugin -->
<input type="text" name="time"></input> <!-- timepicker plugin -->
Now as a rule I have always used a DATETIME column whenever I have needed to store date/time, however this is the first time I'm having to store a user inputted date/time.
I figured it would be best to have seperate DATE and TIME columns, because it would be easier to insert / retrieve the data to / from my application. For example I won't have to combine the values from the two input fields to create a single value to insert in to the database. And likewise I won't have to split a single value in to two values to populate the form fields in edit mode.
But on the other hand won't it be easier to query the table if I used one column? What do you think?
You should build bottom-up (database at the bottom). Don't think about the application, just the database. Now, what makes sense at the database level. DateTime.
So you need to write extra code at the application level.
Please see it
Adding a Timepicker to jQuery UI Datepicker
http://trentrichardson.com/examples/timepicker/
convert your date time according to your mysql format and store it
$mydate = strtotime($_POST['date']);
$myfinaldate = date("d-m-y", $mydate);
$mytime = strtotime($_POST['time']);
$myfinaltime = date("H:i:s", $mytime);
Seperating columns is unlogical. You can use timestamp as datatype and you can use mktime function to parse date and time easily.
Doesn't it depends on the system you're creating.
If you want to store dates beyond 2038 I would store the datetime and time separate.
what if you are developing a reservation application and at one end you need to know on what date and at what time to schedule an appointment for a user, and at the other end, you need to match the user to a doctors schedule. You save the doctors schedule in a database and you need to know (amoung other things) when the doctor is available (on what days), and at what times. Let us forget about the on what days for a moment, and focus on the time shedule first...
You need to develop a programmable schedule so that if you know that the doctor works 6 months in a particular calendar year. (Jan - Jun), He or she may work (9-5 M,W,Fr), and (10-3 T,Th). Sat and Sunday the doctor is off. So you develop a table to hold the Daily time schedule with 2 columns to hold the daily starttime and daily end time for each day of the week. 14 columns in total and a primary and possibly secondary key. So now its time for some date arithmetic (This is where it gets hairy:-|...
You can say i your query: (mySQL)
Select such and such...
where form.theapptdatetime between doctorschedule_startime_tuesday and doctorschedule_endime_tuesday
and this will do a match to see if your datetime is within the date range of your doctorschedulestartime and endtime... but what if all you need is the time??
will the date arithmetic still work if the time value is stored as a datetime???
In other words if I have 01:00:00 as my doctorschedule_startime, is this a legitimate date value for my arithmetic to work, or will a date portion be forced upon me.
Perhaps I should store the time as a varchar, and convert it to a suitable datetime value and perform the arithmetic in the code instead of the query????
An example comes to my mind as to when have date and time split:
You could want to have DATE a part of the unique index, so that a user is only allowed to add 1 record to some table per date, but still you want to know the TIME he added it, so you keep DATE and TIME separate.