Comparing the datetime between the start and end of your execution isn't really a reliable way to determine how close you are to the limits.
The documentation on current governor limits tells us that for a synchronous transaction, the total maximum time allowed is 10 minutes (600 seconds).
Of that, a transaction can consume 10,000 milliseconds (10 seconds) of CPU time, and if you have callouts, those can consume up to a total of 120 seconds. Time spent actually in the database when you make a query doesn't count towards the CPU governor limit.
A more reliable indicator would be to track the CPU limit, which you can do by calling
That said, the CPU limit is one that has been a "soft" limit. Salesforce won't necessarily cut you off if you exceed the CPU limit (depending on several factors, like current load on your pod), but they guarantee that your transaction will not be cut off if it consumes less than the prescribed 10,000 ms (assuming you don't run into exceptions or other limits, that is).
There was also session at Dreamforce last year (DF 2017) on Salesforce platform limits that suggest that the CPU limit (and I believe a few others) are going to start moving towards a 3-tier monitoring system. One is a threshold under which no action is taken (akin to governor limits today), one is an absolute maximum threshold, and then the limit in the middle depends on how often and by how much you exceed the low threshold.
The talk of these threseholds begins at 24:36 in the video.
29:17 begins the discussion of when Salesforce plans to roll that out (should be here now that Summer '18, API v43.0 has been released)