procedure is deleting data instead of inserting
There are several problems here:


No explicit BEGIN TRAN / COMMIT / ROLLBACK around the INSERT and DELETE to group them as an atomic operation.
No TRY / CATCH structure to manage COMMIT vs ROLLBACK.
Why are you using UNIX time instead of actual DATETIME values?
Why no WHERE condition on the SELECT that feeds the INSERT?
But most directly related to the stated question: the entire DayTempTable table gets deleted because the WHERE condition of the DELETE statement is a simple boolean expression and does not reference any field of that table. Meaning, if (@datenow-@date1)&gt;=86400 evaluates to true, then all rows will be deleted. Else, no rows will be deleted. If you want a subset of rows to be deleted, you need to actually filter the table ;-).
An alternate approach to the INSERT then DELETE within an explicit Transaction is to handle both operations at the same time via the OUTPUT clause:

DELETE tbl
FROM   DayTempTable tbl
OUTPUT DELETED.problem, DELETED.channel_number, DELETED.username, DELETED.app_id,
       DELETED.Is_On, DELETED.logtype, DELETED.viewing_channel, DELETED.playtime,
       DELETED.macaddress, DELETED.wifimacaddress, DELETED.seen, DELETED.version,
       DELETED.date
INTO   FinalLogs (problem, channel_number, username, app_id, Is_On, logtype,
                  viewing_channel, playtime, macaddress, wifimacaddress, seen,
                  version, date)
WHERE  (@datenow - tbl.[date_field]) &gt;= 86400;


And then you don't need the explicit Transaction (i.e. BEGIN TRAN / COMMIT / ROLLBACK) since it is handled automatically. But you should still do the TRY / CATCH.

Even better would be to change the WHERE condition to be a simple, sargable expression:

WHERE  tbl.[date_field] &lt;= (@datenow - 86400);



Also, I wouldn't use the term "temporary table" to refer to the DayTempTable table since it is not, in fact, a temporary table (which is denoted by having either a single or double pound sign # as the leading character(s) of the table name).