Traditional database design recommends (strongly) that your PK should be a value that has meaning within the DB (an Int, auto-number or something equiv) and not something meaningful to users (such as dates) because meaningful values tend to result in PK collisions and awkward validation logic. Things are much simpler if you stick with the recommended/classic approach.
Sometimes, a complex key may seem like a better approach, but you don't usually gain much. However, you usually do incur complexity.
So, stick with option 1 and maybe apply an index to represent option 2 instead of a PK.