I have a blog where users can comment. I insert the time at which they posted a comment using NOW() and then use date('j M Y', stored timestamp) to show the time at which they posted.
I want to know does NOW() return the locatime of the end user or the localtime at my server.
Is it better suited to use UNIX_TIMESTAMP than NOW() to calculate the localtime at which users posted a comment.
The function NOW() generates a formatted date-time string, determined by the time zone of your MySQL server.
However, it would be better to store times using UNIX_TIMESTAMP(), which is expressed in GMT. Doing so makes it easier to format it according to the country of a visitor (e.g. using JavaScript).
If you still want to use DATETIME columns, you can store times using UTC_TIMESTAMP() (it formats a date like NOW() but expresses it in UTC); it should more or less work the same in all other aspects.
MySQL UNIX_TIMESTAMP() returns a Unix timestamp in seconds since '1970-01-01 00:00:00' UTC as an unsigned integer if no arguments are passed with UNIT_TIMESTAMP().
When this function used with date argument, it returns the value of the argument as an unsigned integer in seconds since '1970-01-01 00:00:00' UTC.
Argument may be a DATE, DATETIME,TIMESTAMP or a number in YYYYMMDD or YYMMDD.
Note : Since UNIX_TIMESTAMP() works on current datetime, your output may vary from the output shown.
NOW() returns the current date and time.
SELECT NOW(), UNIX_TIMESTAMP(NOW());
+---------------------+-----------------------+
| NOW() | UNIX_TIMESTAMP(NOW()) |
+---------------------+-----------------------+
| 2011-10-03 10:22:37 | 1317666157 |
+---------------------+-----------------------+
Let's see what the manual has to say about NOW():
Returns the current date and time as a value in 'YYYY-MM-DD HH:MM:SS'
or YYYYMMDDHHMMSS.uuuuuu format, depending on whether the function is
used in a string or numeric context. The value is expressed in the
current time zone.
... and UNIX_TIMESTAMP():
If called with no argument, returns a Unix timestamp (seconds since
'1970-01-01 00:00:00' UTC) as an unsigned integer. If UNIX_TIMESTAMP()
is called with a date argument, it returns the value of the argument
as seconds since '1970-01-01 00:00:00' UTC. date may be a DATE string,
a DATETIME string, a TIMESTAMP, or a number in the format YYMMDD or
YYYYMMDD. The server interprets date as a value in the current time
zone and converts it to an internal value in UTC.
So, to begin with, they return different things: a proper date versus an integer.
You actually need to get three features:
Store all dates in the same format (either UTC or the server's time zone)
Obtain user's time zone
Display stored date in user's time zone
The Date and Time functions chapter offers a summary of available functions. If you want to store dates in UTC you'd go for UTC_TIMESTAMP(). If you want to use server's time zone you can use NOW(). And there's CONVERT_TZ() to make conversions.
MySQL, however, won't help you with point #2. You need to either ask the user or use JavaScript to read user's clock and send it to the server so you can guess (if you don't ask you'll always need to guess because there're normally several time zones that share the same time in a given instant).
Related
I would like some confirmation on how NOW function works in MySQL
According to the docs and when runing the this query SELECT NOW() the mysql returns the current time (local time i guess?) in following format YYYY-MM-DD HH-MM-SS.
If this is the case, then how come this works when comparing NOW() to a column that includes a UTC ISO date and time?
For example this works fine:
SELECT * FROM table where deadline > NOW() # deadline column contains a utc ISO string
Is the query above reliable or did it just return the correct answer by luck?
in case this is NOT reliable, how would you do the comparison?
MySQL NOW()-function returns a datetime in the session timezone. MySQL has UTC_TIMESTAMP()-function which returns current UTC date and time, which will work better when you are compare it to an UTC date time.
Note that you should store datetimes as DATETIME, instead of char/varchar (assume this is what you meant by "UTC ISO date and time").
This is the date: 2018-01-25T13:39:40-05:00
Its from an API.
So far, I did this: SELECT UNIX_TIMESTAMP(STR_TO_DATE('2018-01-25T13:39:40-05:00', '%M %d %Y %h:%i%p')) AS time
But its giving me NULL.
I think -05:00 is timezone. But T is, I don't know.
Maybe perhaps there is another way take out T and -05:00 and convert 24hrs to 12hrs
You don't have to use the STR_TO_DATE function.
You can directly use UNIX_TIMESTAMP.
UNIX_TIMESTAMP() is called with a date argument, it returns the value
of the argument as seconds since '1970-01-01 00:00:00' UTC.
The date argument may be a DATE, DATETIME, or TIMESTAMP string, or a number in YYMMDD, YYMMDDHHMMSS, YYYYMMDD, or YYYYMMDDHHMMSS format.
The server interprets date as a value in the current time zone and converts it to an internal value in UTC. Clients can set their time zone
https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_unix-timestamp
SELECT UNIX_TIMESTAMP('2018-01-25T13:39:40-05:00') AS time
http://sqlfiddle.com/#!9/b2206f/1
I need to store both time and date in the mysql. So I used of NOW() function for that. But I don't know what should I use for type column im phpmyadmin. It should be noted that NOW() returns both time and date like this:
2014-11-11 12:45:34
Here is a solution, I can use of a separator for separating date and time (2014-11-11 and 12:45:34) and then store them in the DATE type and TIME type individually. Or I can use of VARCHAR type for storing both of them in one column. But I think these ways are not standard. what is standard type for storing both date and time ?
Here is my query: (also I don't know why NOW() function does not works)
INSERT INTO table (timedate) VALUES (NOW())
DATE: It is used for values with a date part but no time part. MySQL retrieves and displays DATE values in YYYY-MM-DD format. The supported range is 1000-01-01 to 9999-12-31.
DATETIME: It is used for values that contain both date and time parts. MySQL retrieves and displays DATETIME values in YYYY-MM-DD HH:MM:SS format. The supported range is 1000-01-01 00:00:00 to 9999-12-31 23:59:59.
TIMESTAMP: It is also used for values that contain both date and time parts, and includes the time zone. TIMESTAMP has a range of 1970-01-01 00:00:01 UTC to 2038-01-19 03:14:07 UTC.
TIME: Its values are in HH:MM:SS format (or HHH:MM:SS format for large hours values). TIME values may range from -838:59:59 to 838:59:59. The hours part may be so large because the TIME type can be used not only to represent a time of day (which must be less than 24 hours), but also elapsed time or a time interval between two events (which may be much greater than 24 hours, or even negative).
I have a slightly different perspective on the difference between a DATETIME and a TIMESTAMP. A DATETIME stores a literal value of a date and time with no reference to any particular timezone. So, I can set a DATETIME column to a value such as '2019-01-16 12:15:00' to indicate precisely when my last birthday occurred. Was this Eastern Standard Time? Pacific Standard Time? Who knows? Where the current session time zone of the server comes into play occurs when you set a DATETIME column to some value such as NOW(). The value stored will be the current date and time using the current session time zone in effect. But once a DATETIME column has been set, it will display the same regardless of what the current session time zone is.
A TIMESTAMP column on the other hand takes the '2019-01-16 12:15:00' value you are setting into it and interprets it in the current session time zone to compute an internal representation relative to 1/1/1970 00:00:00 UTC. When the column is displayed, it will be converted back for display based on whatever the current session time zone is. It's a useful fiction to think of a TIMESTAMP as taking the value you are setting and converting it from the current session time zone to UTC for storing and then converting it back to the current session time zone for displaying.
If my server is in San Francisco but I am running an event in New York that starts on 9/1/1029 at 20:00, I would use a TIMESTAMP column for holding the start time, set the session time zone to 'America/New York' and set the start time to '2009-09-01 20:00:00'. If I want to know whether the event has occurred or not, regardless of the current session time zone setting I can compare the start time with NOW(). Of course, for displaying in a meaningful way to a perspective customer, I would need to set the correct session time zone. If I did not need to do time comparisons, then I would probably be better off just using a DATETIME column, which will display correctly (with an implied EST time zone) regardless of what the current session time zone is.
TIMESTAMP LIMITATION
The TIMESTAMP type has a range of '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC and so it may not usable for your particular application. In that case you will have to use a DATETIME type. You will, of course, always have to be concerned that the current session time zone is set properly whenever you are using this type with date functions such as NOW().
Saty described the differences between them. For your practice, you can use datetime in order to keep the output of NOW().
For example:
CREATE TABLE Orders
(
OrderId int NOT NULL,
ProductName varchar(50) NOT NULL,
OrderDate datetime NOT NULL DEFAULT NOW(),
PRIMARY KEY (OrderId)
)
You can read more at w3schools.
In shorter explanation
DATE: The DATE stores a date value in the form YYYY-MM-DD (year-month-day). It does not store time.
TIME: The TIME stores a time value in the form HH:MM:SS (hours-minutes-seconds). It does not store the date.
DATETIME: The DATETIME stores a date and time value in the form YYYY-MM-DD HH:MM:SS. It stores both the date and time.
TIMESTAMP: The TIMESTAMP is similar to the DATETIME, but includes a timezone. (Example of values YYYY-MM-DD HH:MM:SS +HH:MM, YYYY-MM-DD HH:MM:SS -HH:MM. +HH:MM and -HH:MM indicate the time zone from UTC (Coordinated Universal Time).
I posted a question as to why the following query filed to search the date.
SELECT * FROM Stuff Where Sell_by <= 2013-07-04;
I was given the newbie answer of "You are searching for the result of the equation 2013-07-04"
That makes perfect sense to me. So I use the following and it come out just fine:
SELECT * FROM Stuff Where Sell_by <= '2013-07-04';
But it raises another question: If 2013 minus 7 minus 4 is 2002. (I assume that is what MySQL is saying)
When is day Zero? (And what is there any significance to that date?)
The answer depends on what Sell_by is. Your basic types to store dates are DATE, DATETIME, and TIMESTAMP. From the MySQL manual:
The DATE type is used for values with a date part but no time part.
MySQL retrieves and displays DATE values in 'YYYY-MM-DD' format. The
supported range is '1000-01-01' to '9999-12-31'.
The DATETIME type is used for values that contain both date and time
parts. MySQL retrieves and displays DATETIME values in 'YYYY-MM-DD
HH:MM:SS' format. The supported range is '1000-01-01 00:00:00' to
'9999-12-31 23:59:59'.
The TIMESTAMP data type is used for values that contain both date and
time parts. TIMESTAMP has a range of '1970-01-01 00:00:01' UTC to
'2038-01-19 03:14:07' UTC.
It doesn't really make much sense to call January 1st, 1000 "day zero", though, at least in my opinion. It happens to be the earliest day representable by DATE and DATETIME, but it has a well-known value that's different from zero, namely the first day of the year 1000.
Okay, by that logic you could argue that 1970-01-01 doesn't have the right to call itself zero, either. But this starting date for TIMESTAMP is chosen as the beginning point of Unix time. And since that time format is defined as "let's count the seconds that happend since the beginning of 1970" (...ish), it really does start with a zero.
Long story short, there is no "day zero", only things that could be interpreted as zero, depending how you look at them.
http://dev.mysql.com/doc/refman/5.6/en/datetime.html says:
MySQL retrieves and displays DATE values in 'YYYY-MM-DD' format. The supported range is '1000-01-01' to '9999-12-31'.
Later:
Invalid DATE, DATETIME, or TIMESTAMP values are converted to the “zero” value of the appropriate type ('0000-00-00' or '0000-00-00 00:00:00').
Read the page for more details.
I have a value stored as a DateTime (Paris date-time).
How can I, into a VIEW, know if a stored date is before or equal to NOW(), with NOW() at Paris TimeZone in any case?
PS : I do not have any control over the SQL server.
To Ensure that the date is in paris time zone you can use CONVERT_TZ to convert between time zones. For example the following query will compare the NOW() date with the stored date and gives you the difference (in days) between them, ensuring that the two dates are in a specific time zone, (I don't know the time zone of paris but this is just an example):
select datediff(
Convert_TZ(Now(),"SYSTEM","-08:00"),
Convert_Tz(AddedIn,"SYSTEM","-08:00")
)
from TableName
System returns your current time zone, and for -08:00 is the time zone that you want to convert to as an offset, you can use the name of the time zone or it's offset as specified MySQL Time zone design pattern.
Hope this will help;