Current Date/Time: (JavaScript)
(Sorry, it doesn't appear that your browser currently supports JavaScript.)

Current Date/Time: (PerlScript^{1})
(Sorry, it doesn't appear that you have PerlScript installed.)

This section shows the output of two clientside scripting languages: JavaScript and PerlScript.
Why JavaScript? It's arguably the de facto standard for clientside scripting on the web, winning out over VBScript, Flash/Actionscript, even clientside PerlScript (*sigh*). ^{1} Why PerlScript? Mostly as an interesting aside (something from a longago use case which serves now as a cautionary tale). TLDR, it's a bad idea. Still curious? Perhaps this topic on stack overflow would be of interest. 
Roughly speaking, epoch is the time in seconds that have elapsed since computers starting counting. For our purposes we'll call that 0 hours, 0 minutes, 0 seconds starting from January 1, 1970. If interested in more info, I defer to this article about epoch definition.
Epoch is useful in computer programming because we can use it to compare dates mathematically which helps us write programming logic with it by converting a humanreadable date format into its equivalent in epoch.
I've had a number of inquiries into how to do the conversion. I figured folks interested in that level of detail would use the source code for this page to ascertain the approach used here. However, I suppose assuming everyone enjoys deciphering the idiosyncrasies of JavaScript for fun was a bit naive... my bad. I'll take a stab at explaining what the code does.
First off, the easiest way to get the current time in epoch (using JavaScript), is to call getTime() method of the JavaScript Date object and divide the return value by 1000. getTime returns the number of milliseconds elapsed, in your computer's timezone, since 1/1/1970 GMT. Because epoch is measured in seconds, you then want to divide the return value by 1000 to change milliseconds into seconds. Keep in mind that the JavaScript Date object will get it's time from your computer's clock. Here's a really simple example doing this.
Note: We're subtracting the milliseconds in order to get a whole number instead of a fraction. You could probably use parseInt similarly, in fact, here's another miniexample demonstrating the differences between (a) getTime()/1000 alone  sometimes a fraction is returned, (b) method above, (getTime  milliseconds)/1000, and (c) parseInt(getTime/1000).Er ok... if you have a human friendly date/time that you want to convert, but you are shall we say "tool averse" or you just enjoy mental gymnastics (good for you, btw), I'll take a stab at explaining a process for doing this manually.
Keep in mind that an accurate description of what the JavaScript Date Object methods are doing isn't in scoperather my effort to explain will be conceptual. (So easy even a Geico customer could do it, my caveman friend likes to say ;)
You could do a rough calculation as follows:
For kicks and giggles let's use for our example a day that many folks will recognize, April 15, . And, we'll say it's 08:30 in the morning just to add some spice to this effort.
Start with the year: . Subtract out 1970 from the year.  1970 leaves us with years. (Sanity check)
Convert the years to days. So years multiplied by 365 days in each of those years. This gives us days.
Now the first relatively difficult issuedealing with leap years. Like me, you may have had it explained to you that roughly every four years can be a leap year...with some caveats. Actually, (as a helpful individual has pointed out to me) the real rule is as follows: Years that are evenly divisible by 100 are not leap years, unless they are also evenly divisible by 400, in which case they are leap years, bringing the total number of days in that year to 366.
We need to examine each of the years between our target and the 1970 starting point. (This is one reason a tool is so great. You don't have to brute force the effort.) Writing a quick script to determine the calculation...
Want to sanity check whether a specific year is a leap year? (Uses algorithm in isLeapYear function code example above to calculate leap year.)
So, we need to add .
Now we need to factor in the months in the current year and convert to days. In our example, we're using April 15, so we have 15 days for the current month. January has 31 days, February has 28unless this year is a leap year in which case it has 29. If this is a leap year, we caught it in our leap year check above. March has 31 days. Adding these up we get 15 + 31 + 28 + 31 = 105 days. Adding that back in to our running total of days we get
Now that we've got all of the days, let's convert those to seconds. It turns out that there are roughly 86,400 seconds in each day. (See the chart below for more useful conversions.) So we take and multiply it by 86400 to get seconds which have elapsed up until the beginning of April 15.
Now we need to factor in the hours and minutes that have passed in the current hypothetical day. It's 08:30. In each minute there are 60 seconds, in each hour there are 60 minutes, so we convert the 8 o'clock hour as 8 * 60 * 60. This gives us . Further, we'll convert the 30 minutes since the 8 o'clock hour into seconds, 30 * 60 which gives us . And we add those all back into the seconds so far to get
Lastly, we need to calculate our offset from GMT. Er, and then factor in daylight savings (ugh). In my case, PST, we're 8 hours differentand we participate in daylight savings. So I add (8 * 60 * 60) + (1 * 60 * 60) which gives , back into my running seconds to get my local time.
This should be the epoch time we're looking for. (See sanity checking your results below.) So, we're saying have elapsed since 1/1/1970"0" in computer time. It's not very friendly from a human standpoint, but it's pure gold from a computer programming standpoint.
Plug back into the converter and see how far off March 15, 2006 you are. It's likely that you are off by some amount, probably the offset for your own local timezone. In general, you should always sanity check your results. Two good tests are, checking your results against today (using the current epoch from getTime/1000 for example), and "0" time. If your mechanism passes both tests, that's a good sign.
Another interesting note: I've heard folks suggest using UTC rather than local time. UTC is certainly an appropriate "global" approach to time based applications, particularly when your audience spans the globe; In that case, having a standard time to fallback on is excellent. In order to apply it to your specific locale, you would calculate the target timezone offset from UTC. There are some strange issues that come up. Calculating an offset accurately can be really tough in the real world. For example, Arizona time while correct in Windows, isn't correct in JavaScript. And that's just one example. I'm not an expert on timezones, so I don't know how prolific timezone offset problems are. I'd appreciate feedback from anyone in the know.
Of course, the most relevant question in all of this is "why would I want to do any of this?" I've had the need for this arise many times. One notable example which occurred while working for a web hosting company was that we wanted to turn messaging chunks on/off 3 days after a new signup for services. We had a marketing manager that wanted to play some messaging to our audience of webmasters three days into their experience. Because there is a steady inflow of customers, the exercise is an ongoing one, and relative to each specific account. We needed a way to identify a member of the 3+ day audience and then some logic to trigger the messaging. In turning that need into programming routines, we did the following steps.
By making signup date a variable, this rule can apply to anyone for whom we
want to know 3 days into the future of their signup.
ex: $signup_date = 1041459471 (or whatever the epoch is for any given site)
if ($current_time > ($signup_date + (86400 * 3))) { /* ...then this site was signed up more than 3 days ago show them the relevant message */ }