The interaction of timezones with unix timestamps is a bit tricky so I thought I'd clarify so that people aren't led too far astray by Greg's and Glen's comments. :)
In the POSIX standard, "unix time" does not have a specified timezone. It is universal. For most intents and purposes you can think of them as always being GMT/UTC. (And you can derive the UTC time from a "timestamp" by dividing it by 86400 and looking at the modulus.) Do not ever try to adjust a timestamp by a timezone offset (specifically, do not ever use the code at the end of Glen's note). Timezones are basically used only when "rendering" a timestamp from "unix time" into a "civil time" date/time string.
Let's take an example. PST is GMT-8, and EST is GMT-5. So when it is 3 AM in PST, it is 6 AM in EST. At that exact moment in time, the _timestamp_ is identical in both time zones. If I am sitting at my computer in PST, and you are at yours in EST, and I call you up and read you the current unix timestamp on my computer, it will match yours (assuming our clocks are both set accurately for our timezone).
So, time() always will return the same thing at the same actual moment, anywhere in the world. gmmktime() and mktime(), when given specific time parameters, convert those time parameters FROM the appropriate timezone (GMT for gmmktime(), local time for mktime()), before computing the appropriate timestamp. Again, for most intents and purposes you can imagine that mktime() first converts your input parameters to GMT and then calls gmmktime() which produces a GMT timestamp. (For the purposes of this explanation, please ignore the fact that the PHP documentation says that internally gmmktime() calls mktime().)
HOWEVER, when called with no arguments, gmmktime() uses the current GMT time, and mktime() uses the current local time. So, if you imagine the above conversion taking place where mktime() converts the (current) local time to GMT, it ends up essentially calling gmmktime() with the _current_ GMT time, just like gmmktime() does all by itself.
This is why time(), gmmktime(), and mktime() all return the same exact timestamp, _when called with no arguments_. This is why Glen saw them all produce the same thing.
Greg wrote that gmmktime() will return something different if you are not sitting in the GMT timezone, but this is only true if you have given it arguments from which to construct a timestamp.
So let's look at that situation again. Say I am in PST and it's 3 AM PST. (And therefore it is 11 AM GMT.) mktime() lets me override one field at at time, and the first argument is, conveniently, the hour field. So if I call mktime(3), I get the same answer as mktime(). Makes sense, right? I just told it to give me the timestamp corresponding to 3 AM local time. If I call gmmktime(11), I get the same answer as gmmktime(), since it is currently 11 AM GMT. mktime(3) and gmmktime(11) refer to the same exact point in time, because PST is 8 hours behind GMT. So it makes sense that mktime(3) == gmmktime(11). And sine mktime() == mktime(3) (at this moment), and gmmktime() == gmmktime(11) (at this moment), it makes sense that gmmktime() == mktime().
Now, back to Greg's note about gmmktime() being different. With identical arguments, their output will be different, e.g. mktime(3) != gmmktime(3). This makes sense because 3 AM PST != 3 AM GMT.
Okay, that should be all you need to know to deal with the interaction between timestamps and timezones. Don't ever try to convert timezones by adding or subtracting to the timestamp. Timestamps don't really have timezones, it is apples and oranges, and you'll either get the wrong answer in some situations or end up with code that no one can maintain. Leave it up to the higher-level PHP functions to do the conversion. (If you want to hack things, strtotime is handy and it can work with timezones; let it do the hard work for you.)