Our free unix (epoch) timestamp conversion tools
and converters require the use of
JavaScript enabled and browsers capable of receiving
AJAX XML responses. These calculators are designed to calculate and display the
UNIX timestamp from entered data for standard universal time in month, day, year, hour, minute and second format, based on GMT or other timezones. Click on the related buttons and the UNIX timestamp in seconds will be calculated. The default initial time of midnight 1/1/1970 (0 hours, 0 minutes and 0 seconds) will return the starting point of the UNIX timestamp, 0. You can convert here unix timestamps into
human readable dates/times, dates into timestamps and strings into timestamps. If you are concerned about daylight saving time don't worry, our tools take it into consideration as well.
Daylight saving time
(DST), also summer time in British English, is the convention of advancing clocks so that afternoons have
more daylight and mornings have less. Typically clocks are
adjusted forward one hour near the start of spring and are
adjusted backward in autumn; the ancients lengthened summer hours instead. Presaged by a 1784 satire, modern DST was first proposed in 1907 by William Willett, and 1916 saw its first widespread use as a wartime measure aimed at conserving coal. Despite controversy, many countries have used it since then; details vary by location and change occasionally.
Unix time
or
POSIX time, is a system for describing points in time: it is the number of seconds (timestamp) elapsed since
midnight UTC of January 1, 1970, not counting leap seconds. It is widely used not only on Unix-like operating systems but in many other computing systems. It is neither a linear representation of time nor a true representation of UTC (though it is frequently mistaken for both) as the times it represents are UTC but it has no way of representing UTC
leap seconds (e.g. 1998-12-31 23:59:60).
Unix timestamps
are the number of seconds since midnight, January 1, 1970 GMT (referred to as the Epoch). They are much easier to manipulate than any other date/time strings. For example, if you need to refer to 10 days from today, it is easier to
add (10 days * 24 hours * 60 minutes * 60 seconds) seconds to the current timestamp than using
several conditions to separate the related description words.
Modern Unix time and it's timestamp
is based strictly on UTC. UTC counts time using SI seconds, and breaks up the span of time into days. UTC days are mostly
86 400 s long, but are occasionally
86 401 s and could be
86 399 s long (though the latter option has never been used as of December 2006) in order to keep the days synchronised with the rotation of the Earth (or
Universal Time).
When a
leap second occurs, so that the UTC day is not exactly 86 400 s long, a
discontinuity occurs in the Unix time number. The Unix time number - timestamp increases by exactly 86 400 each day, regardless of how long the day is. When a leap second is deleted (which has never occurred as of
2006), the Unix time number (timestamp) jumps up by 1 at the instant where the leap second was deleted from, which is the end of the day. When a leap second is
inserted (which has occurred on average once every year and a half), the Unix time number increases continuously during the leap second, during which time it is more than 86 400 s since the start of the
current day, and then jumps down by 1 at the end of the leap second, which is the start of the next day.
Any comments are welcome, please visit the
forum
Special Tip
Confused by using
gmdate() and still getting wrong time? It's happening thanks to daylights saving time and wheter the server is in summer or winter time zone. How to fix that and
ALWAYS get the proper base date for all calculations?
<?
function GMT_Time() {
return gmdate("U") + date("Z");
}
?>
|
As you can see, this simple function returns the proper GMT
Timestamp, so to use it in any following code you need something like this:
|
<?=
gmdate("H:i", GMT_Time())
?>
|
Updated (14th April 2005)
Last time we've forgotten a quite important use for our script -
input timestamp
correction. What if we already have our own timestamp and just want to make sure it's correct? Let's modify our function a little bit
<?
# ~~~ GMT Time Magic v2.0 ~~~~~~~~~~ #
function GMT_Time($Stamp) {
return (($Stamp == 0) ? time() : $Stamp) + date("Z");
}
?>
|
Our new GMT Time Magic might look a bit confusing thanks to advanced use of
if/else statement, but don't get disgusted. If you take a closer look, you can see by reading from left to right the following:
IF the incoming
$Stamp IS 0, generate a new timestamp,
ELSE if the incoming
$Stamp IS NOT 0 (reverse of the previous statement), use the original $Stamp value. Then add the daylight saving time modification and return the string. Simple enough, huh?
|
<?=
gmdate("H:i", GMT_Time(0))
?>
|
- or -
|
<?=
gmdate("H:i", GMT_Time($My_Stamp))
?>
|
It's exactly the same script as the one used on this page, so if there's a bug, you can find it out yourself very easily. For any comments, suggestions or bugreports, please visit our
message board and leave your note.
Updated (18th July 2005)
One more place for confusion discovered. There is a difference if you are making the stamp (
mktime) or reading it (
date). Also if your server has offset 0 (GMT Zone), you don't need any of this, because
gmdate() and
gmmktime() work perfectly. So let's see the last version, exactly as used here, no more theories ;)
Note: In this script the incomming timestamp condition is not set to 0, because if you used 0 in the conversion tool it would return the actual time instead of beginning of the epoch. But otherwise its useless, just a visual game.
<?
# ~~~ GMT Time Magic v2.3 ~~~~~~~~~~ #
function GMT_Time($Stamp=0,$Change=0) {
return ((!$Stamp) ? time() : $Stamp) - $Change * date("Z");
}
?>
|
And the final calling code for both commands (number 1 is your server's offset)
|
<?=
date("l, F jS Y, H:i:s", GMT_Time($Timestamp, 1) + 3600 * $Timezone)
?>
|
- and -
|
<?=
GMT_Time($Timestamp, (-1)) + 3600 * $Timezone
?>
|
- src -
