If you use the system variables CDATE or DATE in your autolisp code in AutoCAD 2017 or later, you should know that Autodesk made an (at the time) undocumented change to these system variables. Prior to 2017 these sysvars returned a value that included portions of a second. From 2017 on, these variables are rounded to the nearest second.
For 99% of us, this is not an issue. But if you are timing CAD operations by recording the start time and then the end time and then subtracting the values, on 2017 and later your answer will always be a whole number. If the answer is less than 1/2 of a second, then you will get an answer of 0.0000. Not exactly accurate.
Thanks to Lee Ambrosius for pointing out an undocumented in 2017, but documented in 2018 system variable named MILLISECS. The format of this system variable is not the same as CDATE and DATE, but you can use it to measure time in milliseconds. MILLISECS returns the value of the Windows API function GetTickCount, which is the number of milliseconds elapsed since the PC was started up. (We have not tested, but presume this is not a valid system variable for AutoCAD for MAC)
Below is some sample autolisp code you can use for testing. The 2016 function works fine in 2016 and earlier, but always returns a whole number in 2017 and later. The 2017 function works fine in 2017 and later.
(defun C:2016 ( / begin) (defun gettime ( / s seconds) (setq s (getvar "DATE")) (setq seconds (* 86400.0 (- s (fix s)))) ) (setq begin (gettime)) ; introduce a 1/2 second delay so we have something to time (command "._delay" 500) (setvar "dimzin" 0) (princ (strcat "\n" (rtos (- (gettime) begin) 2 12))) (princ) ) (defun c:2017 ( / s e ) (setq s (getvar "millisecs")) ; introduce a 1/2 second delay so we have something to time (command "._delay" 500) (setvar "dimzin" 0) (setq e (getvar "millisecs")) (princ (strcat "\n" (rtos (/ (- e s) 1000.0) 2 12))) (princ) )