If replication is 600 seconds behind master will INSERT or UPDATE queries including `NOW()` be 600s different? If slave is behind master by 600 seconds, will queries including NOW() also be 600s different?

Example:

master|mysql&gt; INSERT INTO my_table (hash,my_time) VALUES ('foo',NOW());
### 600s later, does slave get the same query?
 slave|mysql&gt; INSERT INTO my_table (hash,my_time) VALUES ('foo',NOW());


Will the following produce the exact same result if run on master and slave?

master|mysql&gt; SELECT my_time FROM my_table WHERE hash = 'foo'; #2016-04-21 09:49:42
 slave|mysql&gt; SELECT my_time FROM my_table WHERE hash = 'foo'; #????-??-?? ??:??:??


Assume SHOW SLAVE STATUS\G shows Seconds_Behind_Master: 600, that master and slave are in the same datacenter (same timezone) and slave doesn't catch up to master until after the above is completed.

If the two are 600s different, what is the best practice to use instead of NOW()?
tl;dr No. 

The binlogs contain a set timestamp command before every transaction exactly to prevent this situation. This will only affect the session scope of the SQL thread so running queries meanwhile won't report date 600 seconds in the past.

To take a look you can run:

$ sudo mysqlbinlog --base64-output=DECODE-ROWS binlog.XXXXX |head -30

#150613  9:06:38 server id 1  end_log_pos 478584 CRC32 0xd86fcd7b   Query   thread_id=88627 exec_time=0 error_code=0
SET TIMESTAMP=1434179198/*!*/;
BEGIN
...