I am running the following query, but there is one random result from the TIMESTAMPDIFF function that is returning a negative value, only one:
select JOB_ID,FROM_UNIXTIME(TIME_STARTED/1000) as TIME_STARTED,FROM_UNIXTIME(TIME_FINISHED/1000) as TIME_FINISHED,TIMESTAMPDIFF(SECOND,FROM_UNIXTIME(TIME_STARTED/1000, '%Y-%m-%d %h:%i:%s'),FROM_UNIXTIME(TIME_FINISHED/1000, '%Y-%m-%d %h:%i:%s')) AS DURATION from JOB;
Here's some of the data returned:
| job_201306051933_0707 | 2013-06-10 23:16:57 | 2013-06-10 23:17:06 | 9 |
| job_201306051933_0832 | 2013-06-11 10:00:47 | 2013-06-11 10:29:03 | 1696 |
| job_201306051933_0850 | 2013-06-11 12:49:57 | 2013-06-11 13:18:30 | -41487 |
Again, that last one is the only negative value returned and I'm not sure why this is. any help is appreciated.
You are using default format for FROM_UNIXTIME() to show time_started and time_finished, but to count time difference you convert your timestamps with '%Y-%m-%d %h:%i:%s' format.
In this format %h means hour 01-12 (AM or PM), therefore your time_finished for the last row is taken as '2013-06-11 01:18:30'. It is an earlier timestamp than time_started in the same row so you get a negative result.
You should use `%H' instead of '%h' for hours to get proper value within 00-23 range.
Or use the same default format you use to show timestamps.
Related
I need to query the info in MySql where I'm given two time strings, so I need to find anything in between.
the format the table looks like
id | date | hour | other | columns | that are not important
-----------------------------------------------------------
1 | 2016-04-11| 1 | asdsa......
2 | 2016-04-11| 2 | asdasdsadsadas...
.
.
.
n | 2016-04-12| 23 | sadasdsadsadasd
Say I have the time strings 2016-04-11 1 and 2016-04-12 23 and I need to find all info from 1 to n. I can separate the date and hour and do a query using BETWEEN...AND for the date, but I have no idea how to fit the time into the formula. Using another BETWEEN definitely won't work, so I definitely need to fit the statement somewhere else. I'm not sure how to proceed though.
WHERE ((`date` = fromDate AND `hour` > fromHour) OR `date` > fromDate)
AND ((`date` = toDate AND `hour` < toHour) OR `date` < toDate)
I have MeasureDateTime (nvarchar(50)) column in my SQL Server table.
I need to get
|measureFilePath | MeasureDateTime | MeasureName |
| 12Nc121 |Thu Jun 19 15:00:05 2011| Annulus 4th RMS (Waves) |
| 12NB121 |Thu Jul 19 15:38:05 2012| 3.0mm 4th RMS (Waves) |
| 12NXc121 |Tue May 15 12:13:02 2012| BC (mm) |
| 12NA121 |Tue May 15 12:13:02 2012| CT (mm) |
| 12Nc111 |Tue May 15 12:13:02 2012| Reference Angle (deg.) |
| 12Nc231 |Wed May 15 12:03:02 2013| Temperature (C) |
I want to get last 6 months of data using the MeasureDateTime column, for example.
But the problem is MeasureDateTime is of nvarchar type.
Anyone know how to do this? Is it even possible?
Try
CONVERT(datetime,SUBSTRING(MeasureDateTime,4,100),101)
to convert the varchar column into a datetime format.
SUBSTRING(MeasureDateTime,4,100) removes the weekday part of the date string and the CONVERT() call with format 101 will accept the US-type date format.
The select could look like
SELECT * FROM table WHERE DATEADD(month, 6, CONVERT(datetime,SUBSTRING(MeasureDateTime,4,100),101)) > getdate()
I ignored the inserted time information before. Here another attempt on the date conversion:
convert(datetime,substring(stuff(dt,11,0,right(dt,5)),4,21),101)
This approach relies on equal string lengths. I don't know for certain whether that is a given here.
This is a bit convoluted but may work:
WHERE DATEDIFF(Month, CAST(RIGHT(MeasureDateTime, LEN(MeasureDateTime) - 4) as datetime), GETDATE()) <= 6
Try using a trigger for this table when inserting. Try the solution provided by #cars10 to get the date and store it in a datetime field. Always keep datetime fields as datetime rather than varchar fields. Later on you my have to retrieve records based on date and this datetime field will prove to be useful.
if i want to get the total_consumption over a range of dates, how would i do that?
I thought i could do:
SELECT id, SUM(consumption)
FROM consumption_info
WHERE date_time BETWEEN 2013-09-15 AND 2013-09-16
GROUP BY id;
however this returns: Empty set, 2 warnings(0.00 sec)
---------------------------------------
id | consumption | date_time |
=======================================|
1 | 5 | 2013-09-15 21:35:03 |
2 | 5 | 2013-09-15 24:35:03 |
3 | 7 | 2013-09-16 11:25:23 |
4 | 3 | 2013-09-16 20:15:23 |
----------------------------------------
any ideas what i'm doing wrong here?
thanks in advance
You're missing quotes around the date strings: the WHERE clause should actually be written as...
BETWEEN '2013-09-15' AND '2013-09-16'
The irony is that 2013-09-15 is a valid SQL expression - it means 2013 minus 09 minus 15. Obviously, there's no date lying in between the corresponding results; hence an empty set in return
Yet there might be another, more subtle error here: you probably should have used this clause...
BETWEEN '2013-09-15 00:00:00' AND '2013-09-16 23:59:59'
... instead. Without setting the time explicitly it'll be set to '00:00:00' on both dates (as DATETIME values are compared here).
While it's obviously ok for the starting date, it's not so for the ending one - unless, of course, exclusion of all the records for any time of that day but midnight is actually the desired outcome.
SELECT SUM(consumption)
FROM consumption_info
WHERE date_time >= 2013-09-15 AND date_time <= 2013-09-16;
or
SELECT SUM(consumption)
FROM consumption_info
WHERE date_time BETWEEN 2013-09-15 AND 2013-09-16;
Its better to use CAST when comparing the date function.
SELECT id, SUM(consumption)
FROM consumption_info
WHERE date_time
BETWEEN CAST('2013-09-15' AS DATETIME)
AND CAST('2013-09-16' AS DATETIME)
GROUP BY id;
It's not actually a problem I'm having, but imagine someone's building a website about the medieval times and wants to store dates, how would they go about it?
The spec for MySQLs DATE says it won't go below the year 1000. Which makes sense when the format is YYYY-MM-DD. How can you store information about the death of Kenneth II of Scotland in 995? Of course you can store it as a string, but are there real date-type options?
Actually, you can store dates below year 1000 in MySQL despite even documentation clarification:
mysql> describe test;
+-------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| id | int(11) | YES | | NULL | |
| birth | date | YES | | NULL | |
+-------+---------+------+-----+---------+-------+
-you still need to input year in YYYY format:
mysql> insert into test values (1, '0995-03-05');
Query OK, 1 row affected (0.02 sec)
mysql> select * from test;
+------+------------+
| id | birth |
+------+------------+
| 1 | 0995-03-05 |
+------+------------+
1 row in set (0.00 sec)
-and you'll be able to operate with this as a date:
mysql> select birth + interval 5 day from test;
+------------------------+
| birth + interval 5 day |
+------------------------+
| 0995-03-10 |
+------------------------+
1 row in set (0.03 sec)
As for safety. I've never faced a case when this will not work in MySQL 5.x (that, of cause, does not mean that it will 100% work, but at least it is reliable with certain probability)
About BC dates (below Christ). I think that is simple - in MySQL there's no way to store negative dates as well. I.e. you will need to store year separately as a signed integer field:
mysql> select '0001-05-04' - interval 1 year as above_bc, '0001-05-04' - interval 2 year as below_bc;
+------------+----------+
| above_bc | below_bc |
+------------+----------+
| 0000-05-04 | NULL |
+------------+----------+
1 row in set, 1 warning (0.00 sec)
mysql> show warnings;
+---------+------+--------------------------------------------+
| Level | Code | Message |
+---------+------+--------------------------------------------+
| Warning | 1441 | Datetime function: datetime field overflow |
+---------+------+--------------------------------------------+
1 row in set (0.00 sec)
But I think, in any case (below/above year 0) it's better to store date parts as integers in that case - this will not rely to undocumented feature. However, you will need to operate with those 3 fields not as the dates (so, in some sense that is not a solution to your problem)
Choose a dbms that supports what you want to do. Among other free database management systems, PostgreSQL supports a timestamp range from 4713 BC to 294276 AD.
If you break up the date into separate columns for year, month, and day, you also need more tables and constraints to guarantee that values in those columns represent actual dates. If those columns let you store the value {2013, 2, 29}, your table is broken. A dbms that supports dates in your range entirely avoids this kind of problem.
Other problems you might run into
Incorrect date arithmetic on dates that are out of range.
Incorrect locale-specific formatting on dates that are out of range.
Surprising behavior from date and time functions on dates that are out of range.
Gregorian calendar weirdness.
Gregorian calendar weirdness? In Great Britain, the day after Sep 2, 1752 is Sep 14, 1752. PostgreSQL documents their rationale for ignoring that as follows.
PostgreSQL uses Julian dates for all date/time calculations. This has
the useful property of correctly calculating dates from 4713 BC to far
into the future, using the assumption that the length of the year is
365.2425 days.
Date conventions before the 19th century make for interesting reading,
but are not consistent enough to warrant coding into a date/time
handler.
Sadly, I think that currently the easiest option is to store year, month and day in separate fields with year as smallint.
To quote from http://dev.mysql.com/doc/refman/5.6/en/datetime.html
For the DATE and DATETIME range descriptions, “supported” means that although earlier values might work, there is no guarantee.
So there's a good change that a wider range will work given a sufficiently configured MySQL installation.
Make sure not to use TIMESTAMP, which seems to have a non-negative range.
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.
Here is a JavaScript example how far before the UNIX epoch(1) you can get with 2^36 seconds * -1000 (to get to milliseconds for Javascript).
d = new Date((Math.pow(2, 36) - 1) * -1000)
Sun May 13 -208 18:27:45 GMT+0200 (Westeuropäische Sommerzeit)
So I would suggest to store historical dates as BIGINT relative to the epoch.
See http://dev.mysql.com/doc/refman/5.6/en/integer-types.html for MxSQL 5.6.
(1)
epoch = new Date(0)
Thu Jan 01 1970 01:00:00 GMT+0100 (Westeuropäische Normalzeit)
epoch.toUTCString()
"Thu, 01 Jan 1970 00:00:00 GMT"
I'm trying to store a 12/24hr (ie; 00:00) clock time in a MySQL database. At the moment I am using the time datatype. This works ok but it insists on adding the seconds to the column. So you enter 09:20 and it is stored as 09:20:00. Is there any way I can limit it in MySQL to just 00:00?
That doesn't look possible. The TIME data type is defined to represent the time of the day (or elapsed time) with a 1 second resolution. However, you can always use the DATE_FORMAT() function to format your field as HH:MM in a SELECT query:
SELECT DATE_FORMAT(NOW(), '%k:%i');
+-----------------------------+
| DATE_FORMAT(NOW(), '%k:%i') |
+-----------------------------+
| 4:09 |
+-----------------------------+
1 row in set (0.00 sec)
SELECT DATE_FORMAT(NOW(), '%H:%i');
+-----------------------------+
| DATE_FORMAT(NOW(), '%H:%i') |
+-----------------------------+
| 04:09 |
+-----------------------------+
1 row in set (0.00 sec)
The TIME column type does not accept any parameter or modifier to define range or precision. You can, however, omit seconds on insert if you are careful:
Be careful about assigning abbreviated values to a TIME column. MySQL
interprets abbreviated TIME values with colons as time of the day.
That is, '11:12' means '11:12:00', not '00:11:12'. MySQL interprets
abbreviated values without colons using the assumption that the two
rightmost digits represent seconds (that is, as elapsed time rather
than as time of day). For example, you might think of '1112' and 1112
as meaning '11:12:00' (12 minutes after 11 o'clock), but MySQL
interprets them as '00:11:12' (11 minutes, 12 seconds). Similarly,
'12' and 12 are interpreted as '00:00:12'.
CREATE TABLE example (
example_id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
elapsed TIME NOT NULL,
PRIMARY KEY (example_id)
);
INSERT INTO example (elapsed) VALUES ('123:45:00'), ('123:45');
SELECT * FROM example;
+------------+-----------+
| example_id | elapsed |
+------------+-----------+
| 1 | 123:45:00 |
| 2 | 123:45:00 |
+------------+-----------+
... and you can remove them on read (if necessary) by applying a proper TIME_FORMAT(), noting that:
If the time value contains an hour part that is greater than 23, the
%H and %k hour format specifiers produce a value larger than the usual
range of 0..23. The other hour format specifiers produce the hour
value modulo 12.
INSERT INTO example (elapsed) VALUES ('2:00');
SELECT example_id, TIME_FORMAT(elapsed, '%k:%i') AS elapsed
FROM example;
+------------+---------+
| example_id | elapsed |
+------------+---------+
| 1 | 123:45 |
| 2 | 123:45 |
| 3 | 2:00 |
+------------+---------+
Since MySQL/5.7.5 you can also use a generated column to get a display value automatically:
-- Completely untested, I don't have 5.7 yet
CREATE TABLE example (
example_id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
elapsed TIME NOT NULL,
-- Size to accomodate for '-838:59:59'
elapsed_display VARCHAR(10) AS (TIME_FORMAT(elapsed, '%k:%i')) VIRTUAL NOT NULL,
PRIMARY KEY (example_id)
);