Date/Epoch Converter

Current Time (from your computer)

What is epoch

Roughly speaking, epoch is the time in seconds that have elapsed since computers started 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 human-readable date format into its equivalent in epoch.

How to Convert between Date and Epoch

I've had many questions about how to do the conversion. It's worth viewing the source code here to understand... if only to find how not to do it. ;-) But, since this topic isn't specifically a programming concern, I'll take a stab at explaining what the code does in english (or as near to it as I can manage, apologies to my teachers in advance).

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.

Hmmm okay... 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 scope--rather my effort to explain will be conceptual.

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 issue--dealing 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 28--unless 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. Hmmm... and then factor in daylight savings (*more sigh*). In my case, PST, we're 8 hours different--and 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 seconds have elapsed since 1/1/1970--"0" in computer time. It's not very friendly for human eyes, but then it's intended for computers; because we can use math now to compare it with other dates--a common problem in programming-related applications.

Plug back into the converter and see how far off our target date 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.

Examples of Usage

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.

1. First, we stored the epoch value of the date of each signup (for example, Jan 1, 2003 is 1041459471 in epoch). Now that the date value is an integer, we can do math with it.
2. Second, we calculate 3 days in epoch measures (seconds) as follows... (86400 * 3)
3. Third, compare the current time with the signup time, plus the 3 days epoch value.

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
  */
}

Common Time Measures in Epoch

Source Code for Converter and Examples