This seems misguided.
Time in seconds from any source lacks almost any entropy, and is almost immediately guessable. If your OS allows microsecond granularity for a running process, you'll get 4 or 5 bits of entropy there, from the lower bits, but a lot less if someone finds a way to get the exact system uptime.
You're then talking about MD5, which isn't really useful in this case. All it does it give you the impression that you've made it more random, without actually making it random. Really you've only got a couple of integers that are dependant on each other (process time is always going to be in sync with system uptime) and that are entirely non-random. Your system will almost certainly leak its uptime in one form or another. You'd actually be better off using an LCG like PHP's
rand(), since the internal state can't be guessed as easily.
This approach to random number generation is bad, because it's not random at all, and can be predicted. However, salts don't actually need to be particularly random, they just need to be unique; they're only there to prevent rainbow table attacks. Unpredictability helps (see "how to store salt?") but isn't entirely required. Regardless, there are some benefits to making the salt difficult to predict.
If you're on Linux, read some bytes from
/dev/urandom to generate the salt - you don't need to do anything more than take those bytes and use them, because they're already strong random numbers.
If not, you could generate the salt as
SHA256(username || email || time || mt_rand()) where
|| denotes concatenation,
time is the current system time in as high a resoluton as you can get, and
mt_rand() is an output value from whatever random generator is available in your programming language's default library. In PHP you should use
mt_rand rather than
rand, since it has better characteristics. This provides enough entropy for a salt to be very difficult to guess remotely, especially given the limited opportunities for re-use of username and email combinations.
For storing the password, you should definitely be using PBKDF2 or bcrypt. A single use of a cryptographic hash function is simply not enough to protect you from bruteforce attacks, especially when almost everyone has an OpenCL-compatible GPU these days.