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;
Related
I am querying a table that has a datetime column and the value is in the format time stamp with time zone. I've tried doing a select hour(timestamp,-5) as NTime and different variants of that, but the furthest I get is an error stating the timestamp is not a valid name/type. I'm officially going off the deep end on this....
Basically, I just need the new alias column values to be a time stamp that is 5 hours behind the timestamp that is in the original table. Thank you all in advance!!
MariaDB / MySQL doesn't have a "timestamp with timezone" data type.
DATETIMEs are simple wall time, and TIMESTAMPs are UNIX time_t timestamps (the number of seconds since 1970-01-01T00:00:00UTC).
You can convert DATETIME values from one time zone to another by with tz_convert().
SELECT tz_convert('2022-04-08 21:53', 'America/Chicago', 'UTC')
for example.
Or, just to do date arithmetic you can do stuff like this.
SELECT '2022-04-08 21:53' - INTERVAL 5 HOUR
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").
I'm using a Laravel application that inserts timestamps based upon 'timezone' => 'America/New_York'. All of my data inserted is the correct date time. Which should be expected. I know that the MySQL's own timezone setting doesn't effect the inserted data.
However, I want to retrieve records from 30 mins ago. But when I use MySQL NOW() function its the wrong time. So I set the time_zone to America/New_York that gives me the correct NOW() but all the record dates have been mutated.
SELECT id, updated_at FROM my_table Where id = 6;
Gives me the correct date in my update_at field;
So to select my records within the past 30 mins is use:
SET #PAST_TIME = DATE_SUB(NOW(), INTERVAL 30 MINUTE);
SELECT id, updated_at, #PAST_TIME as past_time FROM my_table Where updated_at >= #PAST_TIME;
Which returns practically every record in my set and as you can see, the past_time is incorrect (I ran this at 9:31 ET).
Recognizing that the time mysql is out of sync, I set the timezone to
SET time_zone = 'America/New_York';
SET #PAST_TIME = DATE_SUB(NOW(), INTERVAL 30 MINUTE);
SELECT id, updated_at, #PAST_TIME as past_time FROM my_table Where updated_at >= #PAST_TIME;
Which outputs the correct PAST_TIME but all the update_at records are mutated. But it shouldn't return some of those records anyway because the mutated results are greater than PAST_TIME
How do I stop the column mutation? while still being able to select my records?
You can think of a timestamp column as essentially storing a UTC date and time. It really does not matter what the session time zone setting was when the timestamp value was stored if you are initializing it with a function such as now() or current_timestamp(); the date and time will be interpreted in the current time zone and converted to UTC (of course, now() returns a value that is time zone dependent but regardless of what the current session time zone is you should end up with the same UTC date and time after conversion). However, how the timestamp is displayed very much depends on what the current session time zone is, for the timestamp will be converted back from UTC to whatever the current time zone in effect is.
(On the other hand, if you have a datetime column initialized with now() what will be stored will very much depend on the current time zone because there is never any time zone conversion done. But then it will always be displayed the same regardless of what the current session time zone is in effect.)
When you want to retrieve records that were updated within the last 30 minutes, it's natural to have in your query somewhere DATE_SUB(NOW(), INTERVAL 30 MINUTE). When you are comparing NOW() or a value computed from NOW() with a timestamp column, again it should not make any difference what the current time zone is. The timestamp column has implicit time zone information (UTC) and you should retrieve the same records regardless. As I would expect, I see exactly the same id values being retrieved before and after you set the America/New_York time zone (one might see some difference due to the time lapse between the two queries; fewer rows might now have been updated in the last 30 minutes). The difference, which is to be expected, is how the dates and times are displayed.
You do want to set the America/New_York time zone just so the dates and times jive with your local time. But you should still be getting the same records regardless.
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 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).