Description

Identical to mktime() except the passed parameters represents a
GMT date. gmmktime() internally uses mktime()
so only times valid in derived local time can be used.

Like mktime(), arguments may be left out in order
from right to left, with any omitted arguments being set to the
current corresponding GMT value.

Parameters

hour

The number of the hour relative to the start of the day determined by
month, day and year.
Negative values reference the hour before midnight of the day in question.
Values greater than 23 reference the appropriate hour in the following day(s).

minute

The number of the minute relative to the start of the hour.
Negative values reference the minute in the previous hour.
Values greater than 59 reference the appropriate minute in the following hour(s).

second

The number of seconds relative to the start of the minute.
Negative values reference the second in the previous minute.
Values greater than 59 reference the appropriate second in the following minute(s).

month

The number of the month relative to the end of the previous year.
Values 1 to 12 reference the normal calendar months of the year in question.
Values less than 1 (including negative values) reference the months in the previous year in reverse order, so 0 is December, -1 is November, etc.
Values greater than 12 reference the appropriate month in the following year(s).

day

The number of the day relative to the end of the previous month.
Values 1 to 28, 29, 30 or 31 (depending upon the month) reference the normal days in the relevant month.
Values less than 1 (including negative values) reference the days in the previous month, so 0 is the last day of the previous month, -1 is the day before that, etc.
Values greater than the number of days in the relevant month reference the appropriate day in the following month(s).

See Also

User Contributed Notes 19 notes

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

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.

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.

Since 1981 EC Directives have prescribed the start and end dates of summer time in all Member States. There have to date been eight Directives which have set summer-time arrangements for fixed periods. The Summer Time Act 1972 sets the appropriate dates in the UK and summer-time orders have been made as necessary to implement the European Directives. The 9th EC Directive prescribes the start and end dates of summer time as the last Sundays in March and October respectively. These dates are in line with those already operating in the United Kingdom. The 9th Directive provides that these start and end dates should apply indefinitely.---9th EC Directive - 19 January 2001

Article 1For the purposes of this Directive "summer-time period" shall mean the period of the year during which clocks are put forward by 60 minutes compared with the rest of the year.

Article 2From 2002 onwards, the summer-time period shall begin, in every Member State, at 1.00 a.m., Greenwich Mean Time, on the last Sunday in March.

Article 3From 2002 onwards, the summer-time period shall end, in every Member State, at 1.00 a.m., Greenwich Mean Time, on the last Sunday in October.

When attempting to use HTTP's If-Modified-Since features for caching I ran into the problem of being able to compare the GMT date the browser was sending to my own Last-Modified date (stored in a database field). I saw many examples of how to create a GMT date from a unix timestamp, but little on how to actually get a GMT date into a unix timestamp. Perhaps someone has a better way, here's my solution:

I have seen many different hacked versions of this function for people using Windows that want to support dates before Jan 1, 1970. Here is yet another one that is different than others you may have seen! It does not use loops like all the others I have seen!

As an addendum to my previous note (php.net said it was too long and I had to split this part off), I'll leave you with one more fun tidbit. :)

(See the note below this one for a full explanation of timezones versus unix timestamps.)

3 AM PST == 11 AM GMT, right? 11 AM _GMT_ > 3 AM _GMT_ (same timezone) right? So, logically, 3 AM PST > 3 AM GMT. (Makes sense right, it is 3 AM in California 8 hours after it is 3 AM in Greenwich.) Now, because timestamps are timezone-independent (or, always GMT/UTC), you get a strange situation. mktime(3) > gmmktime(3). Even though PST is GMT-8, so PST is less than GMT, mktime(3) is _greater_ than gmmktime(3). At first glance you'd probably expect mktime(3) to be less than gmmktime(3), but because of everything I described before, about how timestamps are always GMT/UTC (or, in some senses, no timezone at all), it ends up being "backwards." (Run a few examples yourself if you don't believe me.) Yet another reason not to try to deal with timezones at the timestamp level!

gmmktime() should ONLY be used to create a timestamp when specifying a specific GMT date and time.

If you want to make a valid time stamp for the current date & time, use mktime() instead.

UNIX timestamps, by definition, store the GMT time relative to the UNIX epoch.

gmmktime() (without any parameters specified) will effectively use the computer's LOCAL time values just the same as if they were explicit parameters, and the resulting time stamp will be incorrect. (The resulting timestamp will actually be offset in the OPPOSITE direction of the local timezone offset from GMT!)