is there any easy to validate a time field entry against the current date and time?i get date and time entry from an user in two separate fields. I used jquery date picker and time picker for both. with the date I had the option to show current date and future dates and not the past dates so it's good. with the time field i have to show all the time but want to somehow validate to see if the time is already gone for that date.I can o away from jquery and just use php if possible. any ideas?g
You can do
$ispast = strotime($field_value) < time();
This will tell if the given time is in the past. The only requirement is that $field_value is in a format that strtotime recognizes. This will interpret the date in the default timezone you have set (see date_default_timezone_set).
Related
Im have a field with date time type. I see in database is always saved other timezone than my default.
When node content is rendered, date looks fine, but when i trying to get node from code i cant render date in correct timezone.
$node->field_customtime->getValue()
I have array of values with standard timezone, when i dump value, the time is wrong.
So i was trying to do it like that:
$value = $node->field_customtime->getValue();
$value = $value[0]['value'];
$date = new \DateTime($value);
$date = $date->getTimestamp();
echo \Drupal::service('date.formatter')->format($date);
And there is still raw date from database (wrong).
I dont know how to correct display date from custom date field. I see in the form correct date (i.e. 11:00 european time) but in database is 10:00. On node page is correct 11:00 so drupal convert it somehow, but how??
I will assume you are using MySQL?
If so then unless you are saving a timestamp the timezone does not matter. It should be saved exactly how you sent it.
If it is a timestamp then the date is automatically converted into UTC for storage and then converted back into whatever timezone you have set in the mysql configuration.
MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. (This does not occur for other types such as DATETIME.)
What you need to check first is how you are saving the date. Are you storing a timestamp?
If not you need to check how the data is saved and see if anything is happening to the date before inserted into the database.
Unfortunately I do not know much about Drupal but after a quick google I have found out that Drupal 7 happens to have a few ways of handling the datetime. It is quite possible that this may apply for Drupal 8 and you simply need to adjust a configuration.
https://drupal.stackexchange.com/questions/3613/the-differences-between-date-time-zone-handling
I have a jQuery datepicker for a user to select a dueBy date (mm/dd/yyyy) that gets stored in a MySQL database. The user can successfully select a date in the datepicker and submit/save the record. I use the following method to convert the m/d/Y to a UTC format:
$date = DateTime::createFromFormat("m/d/Y", $_POST['dueBy']);
$values['dueBy'] = $date->format('U');
Then when the user views the record again, I convert the UTC time back to an easily readable format:
$dueBy = date('m/d/Y', $aQ->dueBy);
I fill the datepicker with the formatted dueBy date where the user can either leave it as is, or can select a new date.
The issue is this: upon updating the record, the date shifts back one (1) day each save. E.g. if it's originally 03/03/2015, it will save to 03/02/2015. If I open and save the record again, it saves as 03/01/2015.
This is the code using to save (exactly the same as when we create the record):
$date = DateTime::createFromFormat("m/d/Y", $_POST['dueBy']);
$values['dueBy'] = $date->format('U');
I've viewed the record each time to view the values, and they aren't decreasing consistently (e.g. one value has reduced by 86390, and then a few minutes later it had reduced by 86368).
Can anyone explain why this is happening, and how to avoid it?
I have not got any code built yet as I need to ask this question before I can start making it.
first what I am doing:
I am going to be making a tournament system on my website and I would like the tournament creators to choose a date and time that tournament will be active for signups and closed for signups.
I believe I will be using www.jongsma.org datepicker as I think it is very nice looking and easy to use for the end user. Link:here
The Question:
After sanitizing the input from the forms date/time do I need to specify for it to be converted from the users (Person inserting the time) local time to UTC before I store the data on the database or does it automatically convert the input from there local time to UTC when the data is being written to the database?
I am using MySQLite
MySQL accepts datetime in this format "Y-m-d H:i:s".
You can always convert different formatted dates into unix_timestamp with strtotime and turn it into mysql date format with:
$unix_time = strtotime($differentFormattedDate);
date("Y-m-d H:i:s",$unix_time);
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.
Is there any way to validate the time field based on the current time. I already posted a simillar question but now i decided to move away from that option and just want to try this.
1) ask an user to select time (I am using jquery timepicker).
2) See if that time is future time and not which is already gone.
I also have a datepicker, so if there is a way to check the time for that date then that would be great. For example, if one user select "august 10 2010(todays date)" from the date picker and then select time using timepicker, let say user select 6am , is there any way to see if that time for that date is already gone? because that user cannot choose a time which is already gone. I am fine if there is any php solution to take these two fields and see if it's a valid entry or not. Please guide me.
I just found that the date picker for the current and future date is working based on system date, I had my system date changed to aug 6th and the date picker started showing from Aug 6th. Any idea if this can be fixed?
You can use mktime() to solve all of those problems. It will create a unix timestamp if the date is correct (otherwise it will return false). And you can also check if the value is greater than the current timestamp (using the time() function).