New answers tagged

2

Use to_timestamp() with an appropriate format template. For string input, with padding to the left like in your example: to_timestamp(lpad("STARTDT", 8, '0') || lpad("STARTTM", 8, '0'), 'YYYYMMDDHH24MISSMS') For integer input, this should be most efficient: to_timestamp(lpad(("STARTDT" * bigint '100000000' + "...


17

Another aspect: SYSDATE() can be different, but NOW() cannot. mysql> select now(6), sysdate(6), now(6), sysdate(6); +----------------------------+----------------------------+----------------------------+----------------------------+ | now(6) | sysdate(6) | now(6) | sysdate(6) | +----...


22

The time returned by NOW(), and other date time functions, is derived from the start time of the query. The THD class here is used to contain all the information for the connection. The NOW() function implementation grabs this value and returns it into the now_time structure. MySQL docs for NOW() also state: NOW() returns a constant time that indicates the ...


2

Didn't find the answer from @nbk satisfying enough for my needs (especially "No, as long as you have no micro seconds in your datetime and a really very slow server, it could be possible"). So I simulated a kind of very slow server. My Linux desktop MB has 6 cores, I made this C program #define COUNT 10000000000L double busy() { volatile ...


1

No, the will be no difference as MysQL Writes in the manual NOW() returns a constant time that indicates the time at which the statement began to execute. This seems to be a diffrent behaviour as all other functions, which are run column by column. CREATE TABLE mytable (id INT AUTO_INCREMENT PRIMARY KEY, Created DATETIME , Updated DATETIME) INSERT INTO ...


Top 50 recent answers are included