I'am using UserCake for UserManagement - in the table userCake_Users there is a column LastSignIn but the value is in this format: 1286066935
with this function I get the right Date
public function updateLastSignIn()
{
global $db,$db_table_prefix;
$sql = "UPDATE ".$db_table_prefix."Users
SET
LastSignIn = '".time()."'
WHERE
User_ID = '".$db->sql_escape($this->user_id)."'";
return ($db->sql_query($sql));
}
but which format is 1286066935?
this is the sql file
--
-- Table structure for table `Users`
--
CREATE TABLE IF NOT EXISTS `Users` (
`User_ID` int(11) NOT NULL auto_increment,
`Username` varchar(150) NOT NULL,
`Username_Clean` varchar(150) NOT NULL,
`Password` varchar(225) NOT NULL,
`Email` varchar(150) NOT NULL,
`ActivationToken` varchar(225) NOT NULL,
`LastActivationRequest` int(11) NOT NULL,
`LostPasswordRequest` int(1) NOT NULL default '0',
`Active` int(1) NOT NULL,
`Group_ID` int(11) NOT NULL,
`SignUpDate` int(11) NOT NULL,
`LastSignIn` int(11) NOT NULL,
PRIMARY KEY (`User_ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
My guess is it's a UNIX Timestamp.
but which format is 1286066935?
It's Unix time. It's the number of seconds since midnight GMT on 1st January 1970.
1286066935 represents 00:48:55 GMT today, 3rd October 2010.
You can convert a Unix timestamp to an 'ordinary' date/time using an online converter like this one. Alternatively you can use the date command, on Linux:
$ date -d #1286066935
Sun Oct 3 01:48:55 BST 2010
It's called a Unix Time Stamp
Basically, in Unix time stamps are represented as the number of seconds from the Unix Epoch or Jan 1, 1970
It's UNIX time: http://en.wikipedia.org/wiki/Unix_time
The time()-function in php (assuming that's what you're using) returns the time in the very same format, for example.
Looks like a UNIX timestamp to me (number of seconds since 1st January 1970.)
Assuming you're using PHP based on that code snippet, you can use the time() function to return the current UNIX timestamp for insertion into your database.
If you wanted to do the processing with your MySQL query, take a look at the UNIX_TIMESTAMP() function.
Probably UNIX time. Number of seconds since 01/01/1970.
Related
I have a database (MySQL 8.0) with four timestamp columns, using the default timestamp settings, i.e. no fraction of seconds. I would like to start using fractions of a second, probably two decimals, so TIMESTAMP(2). The process that generates the data does not always provide a timestamp to column timestamp_column_3 (just renamed the columns as timestamp_column_1 to timestamp_column_4 here) and thus there are many '0000-00-00 00:00:00' in timestamp_column_3. When I tried converting the
timestamp_column_1 by running the following query:
ALTER TABLE table_name MODIFY COLUMN timestamp_column TIMESTAMP(2);
I get the following response:
Error Code: 1292. Incorrect datetime value: '0000-00-00 00:00:00' for column 'timestamp_column_3' at row 74608.
So, two questions:
Why does timestamp_column_3 interfere with my altering of column timestamp_column_1?
How do I proceed to convert all four columns to datatype TIMESTAMP(2)?
I looked around and found this answer to a similar question. But I'd rather not modify the mode of the database as I'm not very inexperienced and this is a production database. Is there a way to adjust the timestamps in the column to the minimum allowed (I assume this is 1970-01-01 00:00:00). I don't really care about the value. Also, I don't understand why the insertion process is allowed to insert these incorrect values as the mode is the following:
STRICT_TRANS_TABLES,
NO_ZERO_IN_DATE,
NO_ZERO_DATE,
ERROR_FOR_DIVISION_BY_ZERO,
NO_ENGINE_SUBSTITUTION
The incorrect values doesn't really matter as we know they don't "exist" but of course it would be nice to have everything correct. What would then be the "correct" value instead of a ZERO_DATE?
-- EDIT -- Add some information
Version: 8.0.18-google
Table:
CREATE TABLE `event` (
`c1` int(11) DEFAULT NULL,
`c2` varchar(32) NOT NULL,
`c3` varchar(32) NOT NULL,
`c4` varchar(64) NOT NULL,
`c5` varchar(64) NOT NULL,
`c6` varchar(64) NOT NULL,
`c7` varchar(64) NOT NULL,
`c8` varchar(64) NOT NULL,
`c9` varchar(128) DEFAULT NULL,
`timestamp_column_1` timestamp NOT NULL,
`timestamp_column_2` timestamp NOT NULL,
`timestamp_column_3` timestamp NULL DEFAULT NULL,
`timestamp_column_4` timestamp NOT NULL,
PRIMARY KEY (`c4`),
KEY `event-timestamp_column_1` (`timestamp_column_1`),
KEY `event-timestamp_column_3` (`timestamp_column_3`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
0, a, b, c, d, e, f, g, , 2021-02-19 07:45:30, 2021-02-19 07:45:29, 0000-00-00 00:00:00, 2021-06-03 20:11:45
The data is added through Google Storage CSV import function and timestamp_column_3 sometimes has no data in the CSV file, i.e. the column is just represented as ,, in the CSV.
Hi I have a log database table in mysql which captures a start date and time and an end date and time.
The start and now the stop time is inserted to the record.
I have a third field which is duration which I would like displayed as hh:mm:ss
The schema looks like this at present
CREATE TABLE IF NOT EXISTS `log` (
`uid` int(20) NOT NULL AUTO_INCREMENT,
`room` int(11) NOT NULL,
`start` datetime NOT NULL,
`stop` datetime NOT NULL,
`duration` datetime DEFAULT NULL,
`participants` int(3) NOT NULL,
`recorded` varchar(3) NOT NULL,
`rec_file` varchar(35) NOT NULL,
PRIMARY KEY (`uid`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT='Log File' AUTO_INCREMENT=106 ;
I'm trying to create a trigger which calculates the duration and writes it to the duration field as data is inserted
Currently the trigger I am trying to debug looks like this
BEGIN
SET NEW.duration = (TIMEDIFF (NEW.start,NEW.stop)) ;
END
The result is the duration field remains set to 0000-00-00 00:00:00.000000
Any suggestions on how to make this work are greatfully recived
Try to add the following :
Change duration type to TIME instead of DATETIME. According to documentation, the result returned by TIMEDIFF() is limited to the range allowed for TIME values.
This is the reason you are receiving all zeros currently.
I assume that stop time will always be later than start time, so I would write the trigger in the following way:
CREATE TRIGGER your_schema.insert_duration BEFORE INSERT ON your_schema.log
FOR EACH ROW SET NEW.duration = TIMEDIFF(NEW.stop, NEW.start);
The result will be in HH:MM:SS format for duration field.
The below is my table definition that automatically inserts timestamp value into each record. All i want to do is let the timestamp use a specific timezone for example in my case i want it to use the current time of British Columbia How do i do that ?
Because when i insert data in the table i do not really pass a timestame value from my php script but it takes the default value.
CREATE TABLE `cfv_postbusupdate` (
`BusNumber` int(11) NOT NULL,
`Direction` varchar(100) DEFAULT 'Not Provided',
`StopNames` varchar(300) DEFAULT 'Not Provided',
`Status` varchar(45) DEFAULT 'Not Provided',
`comments` varchar(150) DEFAULT 'None',
`username` varchar(45) DEFAULT 'anonymous_user',
`dayofweek` varchar(45) DEFAULT NULL,
`time` varchar(20) DEFAULT NULL,
`id` int(11) NOT NULL AUTO_INCREMENT,
`DatePosted` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=utf8;
Timestamps are stored as UTC values ad converted on retrieval to the time zone in use by the application. If you want British Columbia time set the time zone with SET time_zone = 'america/vancouver';
The manual reference is here
use this one: refer this link:https://stackoverflow.com/a/6158432/3242978
-- Make sure we're all working off of the same local time zone
test=> SET timezone = 'America/Los_Angeles';
SET
test=> SELECT NOW();
now
-------------------------------
2011-05-27 15:47:58.138995-07
(1 row)
test=> SELECT NOW() AT TIME ZONE 'UTC';
timezone
----------------------------
2011-05-27 22:48:02.235541
(1 row)
update: 1
According to MySQL docs, the error #1193 occurs when you use wrong code for SQLSTATE.
Message: Unknown system variable %s
And, as you can see on the same page, the SQLSTATE 99003 is not defined.
I inherited a system that keeps track of temperature data related to time. I had asked a previous question about it: (What is the most efficient way to store a collection of temperature values into MYSQL?)
The system has a separate table which is used to keep track of dates (shown below). It contains several descriptor columns of the current day. I am hesitant of the benefits this kind of structure provides, as it seems to add extra weight to do the same thing a few date functions and math can do.
I was told by the creator of the system that it is better to select a range of data by using the DATE_ID with operators instead of a date function.
For example: Let's say you want to collect all temperature information from June 1st, 2012 till the end of 2012, you could do the following.
1) Get the date ID that corresponds to June 1st, 2012. Lets say the id was 23000
2) Get the date ID that corresponds to the end of the year by using something like:
SELECT DATE_ID FROM DATE_REPRESENTATION WHERE DATE_ID >= 23000 AND END_YEAR_FLAG = 1 AND LIMIT 1;
Lets say that one was 23213
3) Now we would have 2 DATE_IDs, which we could just use like so:
SELECT * FROM temperature_readings WHERE DATE_ID BETWEEN 23000 AND 23213;
I feel that it might be better to properly index the 'temperature_readings' table and use date functions. For example:
SELECT ...... actual_date BETWEEN DATE('2012-06-01') AND LAST_DAY(DATE_ADD(DATE('2012-06-01'), INTERVAL (12 - MONTH(DATE('2012-06-01'))) MONTH))
Is there a better solution than what is currently in use in terms of improving the overall performance? In the previous question, I mention that the system uses the data to produce graphs and alerts based on the data selected by date ranges (daily,weekly, monthly, yearly, or a range that a user can specify).
Current table:
CREATE TABLE `DATE_REPRESENTATION` (
`DATE_ID` int(10) NOT NULL,
`DAY_DATE` timestamp NULL DEFAULT NULL,
`DATE_DESC_LONG` varchar(18) DEFAULT NULL,
`MB_DATE_M_D_YYYY` varchar(18) DEFAULT NULL,
`WEEKDAY` varchar(9) DEFAULT NULL,
`WEEKDAY_ABBREV` char(4) DEFAULT NULL,
`WEEKDAY_NUM` decimal(1,0) DEFAULT NULL,
`WEEK` char(13) DEFAULT NULL,
`WEEK_NUM` decimal(4,0) DEFAULT NULL,
`WEEK_NUM_ABS` decimal(4,0) DEFAULT NULL,
`MONTH_LONG` varchar(9) DEFAULT NULL,
`MONTH_ABBREV` char(3) DEFAULT NULL,
`MONTH_NUM` decimal(2,0) DEFAULT NULL,
`MONTH_NUM_ABS` decimal(5,0) DEFAULT NULL,
`QUARTER` char(1) DEFAULT NULL,
`QUARTER_NUM` decimal(1,0) DEFAULT NULL,
`QUARTER_NUM_ABS` decimal(5,0) DEFAULT NULL,
`YEAR4` decimal(4,0) DEFAULT NULL,
`BEG_WEEK_FLAG` decimal(1,0) DEFAULT NULL,
`END_WEEK_FLAG` decimal(1,0) DEFAULT NULL,
`BEG_MONTH_FLAG` decimal(1,0) DEFAULT NULL,
`END_MONTH_FLAG` decimal(1,0) DEFAULT NULL,
`BEG_QUARTER_FLAG` decimal(1,0) DEFAULT NULL,
`END_QUARTER_FLAG` decimal(1,0) DEFAULT NULL,
`BEG_YEAR_FLAG` decimal(1,0) DEFAULT NULL,
`END_YEAR_FLAG` decimal(1,0) DEFAULT NULL,
PRIMARY KEY (`DATE_ID`),
UNIQUE KEY `DATEID_PK` (`DATE_ID`),
KEY `timeStampky` (`DAY_DATE`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
A DATE should be stored internally as just a number, so the only thing I can imagine is that the old person used to store dates as CHAR and suffered for it :)
When MySQL calculates the BETWEEN values, it will do that once, so there will be little math to be done. Add in the standard optimizations (preparing, parameterizing, indexing, etc), and you should be fine.
The formulas might be a little illegible. Maybe you could wrap them in a stored procedure, so you could call GET_LAST_DAY_OF_QUARTER(date) instead of putting all the date math in the SELECT.
since I have launched a podcast recently I wanted to analyse our Downloaddata. But some clients seem to send multiple requests. So I wanted to only count one request per IP and User-Agent every 15 Minutes. Best thing I could come up with is the following query, that counts one request per IP and User-Agent every hour. Any ideas how to solve that Problem in MySQL?
SELECT episode, podcast, DATE_FORMAT(date, '%d.%m.%Y %k') as blurry_date, useragent, ip FROM downloaddata GROUP BY ip, useragent
This is the table I've got
CREATE TABLE `downloaddata` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`date` datetime NOT NULL,
`podcast` varchar(255) DEFAULT NULL,
`episode` int(4) DEFAULT NULL,
`source` varchar(255) DEFAULT NULL,
`useragent` varchar(255) DEFAULT NULL,
`referer` varchar(255) DEFAULT NULL,
`filetype` varchar(15) DEFAULT NULL,
`ip` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=216 DEFAULT CHARSET=utf8;
Personally I'd recomend collecting every request, and then only taking one every 15 mins with a distict query, or perhaps counting the number every 15 mins.
If you are determined to throw data away so it can never be analysed though.
Quick and simple is to just the date and have an int column which is the 15 minute period,
Hour part of current time * 4 + Minute part / 4
DatePart functions are what you want to look up. Things is each time you want to record, you'll have to check if they have in the 15 minute period. Extra work, extra complexity and less / lower quality data...
MINUTE(date)/15 will give you the quarter hour (0-3). Ensure that along with the date is unique (or ensure UNIX_TIMESTAMP(date)/(15*60) is unique).