|
Current Date/Time: (JavaScript)
(Sorry, it doesn't appear that your browser currently supports JavaScript.)
|
| This section shows the output of the client-side scripting language: JavaScriptt. Why JavaScript? (It's arguably the de facto standard for client-side scripting on the web.) How the output for this section is generated is really secondary to the core date-to-epoch and epoch-to-date conversion topic. It's relevance in this example is that DHTML techniques using a client-side scripting language is what updates this webpage with your input without a reload from the server. |
| Epoch has a few meanings (see also http://dictionary.reference.com/search?q=epoch). The definition that we'll use is "0" in computer time. While there are folks who will argue this, for our purposes, this "0" time on our calendar was January 1, 1970 00:00:00 GMT. Epoch is useful in the programming world because it allows us to mathematically compare dates with other dates or some other measure of time. Said another way, it allows us to use a programming algorithm to make decisions regarding a human readable date or time. See the examples of usage section below for more detail. |
|
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 idiosyncracies 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.
However, if you have a human friendly date/time that you want to convert. You can do what this tool does (though it kind of defeats the purpose of having a tool.) You need to consider that the computer (like a calculator) is really good at not making a mistake. We'd have to unravel the Date Object's methods to accurately replicate what they are doing. That goes a little beyond the scope of this tool. :-) (Sorry, call me lazy.) You could do a rough calculation as follows:
Sanity checking your results Plug 1142528400 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.
|
|
1 Millisecond = 1/1000 in Epoch (used frequently with JavaScript conversions)
1 Second = 1 in Epoch 1 Minute = 60 in Epoch 10 Minutes = 600 in Epoch 1 Hour = 3600 in Epoch 6 Hours = 21600 in Epoch 12 Hours = 43200 in Epoch 1 Day = 86400 in Epoch (24 Hours) 1 Week = 604800 in Epoch (7 Days / 168 Hours) 1 Month = (see below... number of days in the month) 28 Days = 2419200 in Epoch (672 Hours) 29 Days = 2505600 in Epoch (696 Hours) 30 Days = 2592000 in Epoch (720 Hours) 31 Days = 2678400 in Epoch (744 Hours) AVERAGE MONTHS IN YEAR = 2628000 in Epoch (365 / 12 = 30.416666666666666666666666666667) (average months) (30.416666666666666666666666666667 * 86400 = 2628000) (average months in Epoch) 1 Year = 31536000 in Epoch (365 days * 86400 seconds) |