gmmktime()

(PHP 4, PHP 5, PHP 7)

取得 GMT 日期的 UNIX 时间戳

说明

和mktime()完全一样，只除了返回值是格林威治标准时的时间戳。

参数总是表示 GMT 日期，因此$is_dst对结果没有影响。

和mktime()一样，参数可以从右到左依次空着，空着的参数会被设为相应的当前 GMT 值。

自 5.1.0 起，$is_dst参数被废弃。因此应该用新的时区处理特性。

Note:gmmktime()内部使用了mktime()，因此只有转换成本地时间也合法的时间才能用在其中。 so only times valid in derived local time can be used.

Example #1gmmktime()在 Windows 中的边界

参见mktime()，date()和time()。

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.)

I had a problem with hosting a UK site on a US server, the times didnt match (obviously) and also didnt account for daylight savings time. The daylight savings dates and times of change differ worldwide, so detecting if the server was in dst wouldnt work (see http://webexhibits.org/daylightsaving/).
Here is a function for creating a timestamp which can be used by date() to create all the parameters required to display the local time (site not server). I have used GMT time to create the timestamp as there is no offset for UK time (+00). 

In addition to GLEN's post on DEC 5th 2007
(Just a note for others)
The results for the three time types Glen listed under "returns" all returned the exact same timestamp
 - 1196812966
Using those three functions will only make the exact same timestamp if the server the code is executed on IS in GMT timezone.
'mktime()' and 'time()' will both return the timestamp for your server time, and will both be the same as eachother.
gmmktime will return a GMT timestamp.
So if run on a server that is NOT in the GMT timezone then gmmktime will return a different timestamp to the other two.

Beware that despite the documentation which states is_dst is ignored, with PHP 5.2 at least, it is not actually ignored and will cause a 1 hour offset on the UTC time returned.
This caused some interesting bugs, especially with the tzdelta function shown from previous posts below - you need to make the final parameter a 0 instead of $ar[8] otherwise you get an off-by-1-hour as a result.
As a result, I now use : 

Here's a play on turgut85's countDays function. I've found it to be more efficient and it accepts unix timestamps rather than arrays. Thanks for the ideas. 

mwwaygoo's code isn't quite right. My understanding is that the relevant dates for changing between daylight saving time in the UK is the third sunday of march and october - not the last sunday!

There appears to be a discrepency between PHP and C timestamps. The C time() and gettimeofday() functions are documented to return based on UTC time, but the value obtained doesn't match the PHP gmmktime() function. Instead, it matches the PHP mktime() function, which is supposed to be local time.
  
It seems that C always uses a UTC timestamp and adjusts to local time through different handling functions (gmtime() vs localtime()). PHP appears to use differing UTC/local timestamps, but single handling functions.
The exception to this rule is the PHP time() function, which appears to behave in the same was as the C version.
In short, if your PHP is working with timestamps created in C (or vice versa) make sure you are comparing apples to apples.

鹏仔微信 15129739599 鹏仔QQ344225443 鹏仔前端 pjxi.com 共享博客 sharedbk.com