(see below edit to address the edited answer)
Although it's still a bit unclear what you're asking, I think it can be said with reasonable certitude that as-asked your assumption is wrong.
Two timestamps -- or any pair of inputs -- producing the same hash does per se not lessen security in any way. Indeed, mapping identical inputs and possibly even different inputs to identical outputs is the very nature of a hash function (cryptographic or not), and perfectly normal. Hashing produces M bits of output from N bits of input where usually (but not necessarily) N is larger than M. If N is larger than M, then of course some different inputs must produce the same output, there is no other way it could be (pidgeonhole principle). If N is equal to or smaller than N, chances are good that if the outputs are the same, then inputs were the same as well (a hash could in principle still have collisions, but with a reasonably good one that's unlikely). It is usually not easy, or even feasible, to tell the input from the output (cryptographic hashes are explicitly designed to make this hard), but verifying if some provided input matches or not can be done. That's what storing hashes of passwords is about, in its most naive form.
All alone by itself, the fact that sometimes you have the same hash value is not a problem in any way. But in some situations, it may become one.
You made mention of "username", "password", and "file". So let's assume you meant to say you have usernames and hashes of passwords stored in a file. Is it a problem if two hashes are the same?
Well yes, in this case it certainly is, unless it happens by pure coincidence. An attacker breaking into the server and stealing the file can now immediately tell users that have the same (unknown) password apart from others which have different, individual passwords.
If nothing else, this means that the attacker has immediately, at the first glance, identified those users where the cost/benefit ratio of attacking is best. Why? Well because by breaking one password you do not only get access to one acount, but to many. Also, it is highly likely (almost guaranteed) that those particular users are using a very common well-known password which they probably use on many sites, too.
Further, if you are doing this regularly for a living, you can make your life a lot easier, since the hash is deterministic, i.e. it always produces the same output for the same input. That's nice, isn't it?
This means that not only can you run a dictionary attack very cheaply (precompute variations of the 1,000 most common passwords once, reuse forever), but you can also cache results instead of spending work on crunching numbers for every user anew. Instead of one user careless enought to use a password from the top-1000-most-stupid-passwords list or a variation thereof, you can attack many at once, at the same cost. Also, you can remember and reuse every single match that you ever find anywhere (even on a different system), which is less work, and has a much better chance of success than brute-forcing randomly. What's worst, you do not even have to do the work yourself since others have already done it...
That is why identical inputs should produce different outputs for different users on the same system, and for the same user on different systems. Because otherwise, compromising one will compromise many. Rainbow table and salt are two keywords you may want to familiarize yourself with (Wikipedia or such) in that context.
There's other (not immediately related) considerations such as the ability to test hundreds of millions of hashes per second on rather modest hardware which make salting as the only precaution somewhat obsolete nowadays, too.
While salting still effectively protects the entire population of users as such, it does not sufficiently protect the targetted individuum. In this context, PBKDF2 and bcrypt are some keywords you may be interested in.
Your method does not just have somewhat lessened security, but it is outright catastropic. That's not because of the hash, however, but first and foreall because you store plaintext passwords, and compare plaintext passwords. Little does the validation with the key (which is not a key at all) help to remedy this.
A hash from a timestamp and the username is mostly public knowledge, it can easily be calculated by anyone if the time of registration is known, and unless it's a at least microsecond precision time, even without knowing the time of registration (could just brute force it). Add to this the fact that you just emailed it around the world. This really adds zero to security.
The purpose of such a "keyfile" or registration code (usually in the form of an URL, not an attachment) is to make sure the provided e-mail address is valid and accessible. Nothing more, really.
As such, it does not need to be super secret or super special. In principle, any kinda random, not immediately guessable 6-8 digit number will do just fine for that purpose. Make it a 16-digit random number if it makes you feel better.
That does, however, not account in any way for the terrible idea of comparing passwords, which of course implies storing plaintext passwords. Note that PHP has an explicit function for that purpose which does the right thing without you even needing to know how to do it. Or, if bcrypt isn't good enough, and you carefully read up on the matter so know what you're doing this one which is much more complicated but can arguably offer better (and worse!) security.