Article for me pointed out three things
The article is talking about a very specifc situation. It's describing how you should define a date dimension in an analysis/reporting data warehouse. Unless that's what you're doing (which I don't think you are... and if you are you should definitely NOT be using Access) it doesn't apply to you.

There's nothing wrong per-se with using a datetime as a primary key it would be an unusual choice. A primary key isn't just unique, it's a unique identifier. In other words, it's the thing that succinctly and uniquely describes the entity a record represents. It's the defining characteristic. You haven't said what you table contains but would you say it's defining characteristic is a datetime? If so then it's an apropriate primary key. Incidentally, that's why it's apropriate in that article, because a date dimension is a list of days and the defining characteristic of a day is a date.

One thing that makes me think a datetime is not a defining characteristic of your entity is this:-
What appears to be happening is that when Access UPDATES datetime
You should almost never need to update a primary key value. If you have to then it didn't do it's job of being a defining characteristic. If you find yourself updating primary keys you are in for a world of hurt. You're going to be dealing with data inconsistencies all over the place or relying on hungry cascades which will tank your performance (I'm not sure Access even supports cascades).

So the answer is that the date might be fine as a primary key but probably isn't.

I think we probably need more info before we can give you really good suggestions though. From what you've said I'm not convinced that you're really dealing with duplicates. I suspect Pradeep was closer to the mark when he said you're looking at different values formatted to look the same. It's hard to be sure from the information you've provided though.
1. What does your table contain?
2. Why are you updating it?