Adding TIME data to a DATE type column in time series table, and what sort of foreign key
When in doubt, keep it simple - just use DATETIME.  I can think of two reasons to flake TIME off into another table, but neither are commonly applicable:


Your table is very large and in use constantly, so you can't afford to block it while changing a data type.  I'd still work around this by adding a new DATETIME column, populating it gradually, and then dropping the old DATE field when possible.
It's very important that you keep your table narrow, and you'll need the time values very rarely.


You've stated that performance is more important than space, but I really wonder if six bytes for DATETIME2(0..2) is really going to make much difference over three bytes for DATE.  You need to value your own time, and the time of everyone who tries to understand your system in the future.

Your question about the PK really should be asked separately.  However, I concur with Rick James that, in this case, you probably don't need a synthetic key (your id field); just index on symbol_id and date.  Assuming you're clustering on the PK, consider putting date first, so you can easily query date ranges.  If you primarily filter (not just join) by symbol_id, then put it first in the index instead.  If you do both, cluster on { date, symbol_id } and index on symbol_id.