|
Current Date/Time: (JavaScript)
(Sorry, it doesn't appear that your browser currently supports JavaScript.)
|
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. |
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 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).
"Tools are all well and good, but I like pain, how do you do this manually"
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 scope--rather 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.
Years
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 .
Months in Days
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.
Hours, Minutes, ...Seconds?
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
Add a dash of craziness...
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 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 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.
Sanity checking your results
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.
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
*/
}