Wednesday, February 23, 2011

Epoch date ruby

Current Time (from your computer)

Current Date/Time: (JavaScript)
1298467132 (Epoch)
Wed Feb 23 2011 18:48:52 GMT+0530 (IST) (Standard)
Current Date/Time: (PerlScript)
(Sorry, it doesn't appear that you have PerlScript installed.)

This section shows the output of two client-side scripting languages: JavaScript and PerlScript. Why JavaScript? (It's arguably the de facto standard for client-side scripting on the web.) Why PerlScript? (I just thought it was cool that there is a PERL interpreter for browsers, rare though it is.) I've left out VBScript, ...sorry. 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.

What is Epoch

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.

How to Convert between Date and 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.

Click to Show Current Epoch Time

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 mini-example demonstrating the differences between (a) getTime()/1000 alone -- sometimes a fraction is returned, (b) method above, (getTime - milliseconds)/1000, and (c) parseInt(getTime/1000).
Click to test

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:
Say its the year 2006. Determining the offset from "0" time in 1970 could be done as follows. 2006 - 1970 = 36 years. However, we haven't accounted for leap years. As I understand it, "the Gregorian calendar adds a 29th day to February 97 years out of 400." (source: http://www.answerbag.com/q_view/530626) If you want to walk through each year in the range and determine whether it's a leap year then have at it (wow, a tool would sure be nice ;-) ). For my purposes I'm going to say ...a leap year occurs approximately every four years. So, 36 / 4 means we'd have roughly 9 extra days during those 36 years. Converting the years to days we have 36 * 365 = 13140 days. And, adding in our "9" for approximate leap years 13140 + 9 = 13149 days.
Now, let's say it's March 15 in that year. We need to calculate the day offset from January 1. January had 31 days, February had 28, and March has so far had 15. So we can add up our days, 31 + 28 + 15 = 74 days. Let's add this back into the days from the converted year. 13149 + 74 = 13223.
Now let's convert our days into seconds (since epoch is seconds elapsed.) Each day has roughly 86,400 seconds in it. So 13223 * 86400 = 1142467200 seconds.
Now we need the time offset since the start of the day. If we say it's 5:00 PM, then we convert 12 hour time into 24 hour time to get 17:00. That's 17 hours that have elapsed since 12:00:00. Each hour is 3600 seconds, so we can do the conversion as follows 17 * 3600 = 61200. Now add that back into the running total 1142467200 + 61200 = 1142528400.
Note: If you have minutes and seconds, they'd need to be added in as well.
What we're left with is 1142528400 seconds since "0" time 1/1/1970. It's not very friendly from a human standpoint, but it's pure gold for computers and calculators in calculating "elapsed time since..." for a date that's been converted to epoch.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.

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.
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.
Second, we calculate 3 days in epoch measures (seconds) as follows... (86400 * 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.

Common Time Measures in Epoch

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)

Source Code for Converter and Examples

1 comment:

TejutejuAugust 30, 2018 at 2:51 AM
Thank you sharing The Information Keep Learning Ruby on Rails Online Training Hyderabad
ReplyDelete
Replies

Subscribe to: Post Comments (Atom)