How do I change just the time in a timestamp (say, from 2014-08-08 14:26:15 to 2014-08-08 08:00:00)? In PHP I would probably get the timestamp from MySQL, modify the time, then update the table, but I figured there might be a function for doing so in MySQL alone.
(I know timestamps are not used for this purpose, and that a datetime would be better, but I don't have control over the DB schema.)
You can format a date (or datetime) into a datetime string, and specify a hard-coded time, ignoring any time component that may be in the original value.
DATE_FORMAT(datecolumn, '%Y-%m-%d 08:00:00')
See http://dev.mysql.com/doc/refman/5.6/en/date-and-time-functions.html#function_date-format for reference doc on that DATE_FORMAT() function.
Related
I am new in php and I saw some programmer store datetime in database by php date() or mysql NOW() or take column as timestamp. I want to know that the difference between these three is and also how to convert these three formats to users local time worldwide.
As per the mysql's law you can have only one timestamp field,no
restrictions for having number of datetime field..
You can set the
timestamp field for onupdate current timestamp or current
timestamp..And these field type not affecting the date insert
method..
If you are using date() function you can set your own
date format..But not in the now()
For date format the syntax check this article https://www.w3schools.com/php/func_date_date.asp
Finaly Datetime and timestampis mysql
date() and NOW()is php
There's a few things to consider:
TIMESTAMP columns are limited to dates between 1931 and 2038, as they're 32-bit timestamp values.
DATETIME columns can go up to the year 9999. While they don't auto-populate like TIMESTAMP values do by default, they're less restricted, you can have as many as you want per table.
When inserting times your PHP clock and your database clock might differ slightly. Using NTP can help narrow that gap, but drifts do happen. PHP's date() function requires formatting into ISO-8601 format for inserting (YYYY-MM-DD HH:MM:SS). The MySQL NOW() function does not, same with UTC_TIMESTAMP().
I strongly recommend using UTC time in your database for a few reasons:
If you store in local time you'll need to store the time-zone as well, and those can change in wild and bizarre ways.
You may need to accommodate other time zones in the future, which means you might have multiple local times in your data where each record might have a different meaning from others.
Your server might get moved between time-zones which can shift all your data.
So store with UTC and render out as local times based on the user's time-zone preference or some sensible default for your application. Remember, time formatting is often a fussy thing, every country has different date formatting standards, and even a single country might have multiple preferences for long-form, short-form, or numerical forms.
I've been studying the differences in usage between MySQL's DATETIME and TIMESTAMP. It seems that it's pretty straight forward with DATETIME. I would use the following procedure:
Choose the default timezone for all dates, such as UTC.
Let user select a date from drop-down.
Create new PHP DateTime object with the chosen date, using the user's timezone settings, such as EST.
Convert the object to UTC, and insert into database.
On another page, retrieve datetime value and make a new DateTime object with it, using UTC timezone.
Convert object to user's local time (EST), and display to him.
Now, it seems that mysql's TIMESTAMP column type can help eliminate all of these conversions.
What would the above steps look like with the TIMESTAMP column type?
Would I need to do "SET time_zone = timezone;" in the beginning of each pageload to set the timezone to the location of the user?
Would it be easier to ONLY use one type of date column type per database? If not, it may require two different sets of functions to produce the right date.
Should TIMESTAMP only be used in columns not intended to be shown to the public (so as not to deal with formatting)? Like when a row was created, last edited, etc.
I have not tested any of this approach, but it seems pretty straightforward =)
You shouldn't need to convert dates, just set the time zone when you
read/write from dB to get everything right.
Yes, you will have to set right time zone after connection to dB is made.
You mean to only use datetime or timestamp? It really depends on how you intend to
use the columns. But there isn't a clear have to do.
Same as above, it isn't wrong formatting your data from the dB, with a timestamp you can return date style strings from the dB so no worries
Traditionally timestamp is associated like you mention, and datetime for other dates.
more on locale/time zone:
MYSQL set timezone in PHP code
I want to store the date and time that a user performs an action on my website into a MySQL database. I'd like to be able to do the following with ease:
Store the date and time as one field in the database
Use a built in PHP or MySQL function to generate the date-time of the action
Store the date-time based on my server's time, and not worry about user timezones.
Order By the date-time field when I query MySQL
Later, display the date-time in many different formats using built in PHP methods
Here are my questions:
What data type should I use in MySQL ( eg. timestamp, datetime ... )?
What method should I use to generate the date-time ( eg. MySQL's now(), PHP's date() ... )?
What PHP method should I later use to format the date-time in various pretty ways ( eg. 23/4/2012, 5pm on Monday, July 2012 ... )?
I would store it as a datetime, not a timestamp.
I normally use the PHP date function and that way if you ever want to store the time relative to the user's timezone you can simply change the timezone based off the user's settings.
When you pull it out of the database, use strtotime() to convert it, then you can use all the date() features to display it however you want. Example:
echo date('F j, Y',strtotime($db_datetime)); //Displays as 'March 5, 2012'
I've struggled with this question for years, and I'm beginning to think that the best way might be to store the time as an integer that represents Unix time (number of seconds from Jan 1, 1970). I've done this and it works fine.
Personally I've never used datetime, and I can't think of a situation when I ever would use this. It just carries too many problems with it.
Timestamp is a lot better, but in MySQL it can't store a date later than 2032.
I would love to hear some serious discussion on this topic, but Stack Overflow might not be the best place for this.
If you set the mysql data type to a non-nullable timestamp, then save rows with a null value for that column, mysql will automatically update the timestamp for you.
As for reading it back out again, you can just use php's strtotime and the date object to get it into the format you need.
You should use the datetime datatype for your requirement.
It will store both the date and time from your input field based on your query.
For retrieving the datetime you can use the mysql's date_format() function or PHP's date() function.
The datetime will always be stored according to the server's time and not on the clients time.
If I use the PHP's Time() function and in MySQL there are 4 fields DATE, DATETIME, TIMESTAMP, and TIME, which one I should use?
In PHP I use the Time() to record both the Date and the time like 5/10/2012, and the time is used to calculate the time elapsed.
Use what you need:
DATE:
stores only days ex: 2012-06-11
DATETIME:
stores days and time ex: 2012-06-11 12:49:31
TIMESTAMP:
stores days and time ex: 2012-06-11 12:49:31
MySQL has function that sets this field to current timestamp, when there was update in the row.
Maybe (don't know right now) can be specified by number. Others must be specified 'yyyy-mm-d hh:mm:ss'
to convert DB value to PHP's time use strtotime()
I would suggest you to use MySQL Data And Time functions instead. If you need to store current time, use NOW(). It's DATETIME type. Alternatively, you can use Unix Timestamp storing it as INT.
The Unix timestamp is the most basic form of a time/date- a "raw format", if you will. Once you have a timestamp, you can get to any other format you want. Personally I don't see the point in storing DATEs or DATETIMEs, only to convert it to a timestamp when you retrieve the data again, which of course you will need to do if you want to display a date/time in any readable format (see date() function).
MySQL has a field time that store the current timestamp when a record is created. Alternatively, and if you want more flexibility, PHP's time() function returns the current timestamp. PHP also has functions for calculating the timestamp at a certain point in time (e.g. if you want to specify a date in dd/mm/yyyy format).
So in summary, I would always use timestamps, and I recommend you do too, unless you have very specific needs.
I'm retrieving a unix timestamp from a DB and I want to check if this datetime has passed already.
I tried using an if statement to compare to time() but it always says the time has passed already.
What am I doing wrong?
EDIT: Just some more info..to determine am/pm I'm adding 12 to the hour if its PM before running it through mktime(). (Is this right?)
It's stored in the DB as int not as any datetime types.
Your PHP time could be affected by PHP's timezone. Use date_default_timezone_get() to find out what time zone you're in.
Make sure the timezones in the DB and PHP are the same, use NOW() function to fill the DB column with current timestamp (the column should be of datetime type), then you can get the timestamp using UNIX_TIMESTAMP() MySQL function which compares against PHP's time() just nice.
Alternatively, you can fill the DB column with something like
mysql_query("INSERT INTO your_table (your_date) VALUES (FROM_UNIXTIME(" . time() . "))")
That should work even with timezone discrepancies.
If you are using mktime to create a UNIX timestamp, PHP is using the timezone settings to interpret what you mean by the given parameters. It's possible that you should be using gmmktime. It depends on how the timestamps in the database are being created; I cannot say for sure without seeing more code and having a more detailed explanation.
I generally prefer to simply store all dates as DATETIME types in the UTC (GMT) timezone. It tends to be less confusing.
Just some more info..to determine am/pm I'm adding 12 to the hour if its PM before running it through mktime(). (Is this right?)
12 PM is hour 12.
1 PM is hour 13.
So you don't always add 12. (i.e., 12 Noon is the exception).