DD Countdown Script II - Eastern Time Zone?

[thomas]

Script: DD Countdown Script II
http://www.dynamicdrive.com/dynamic...dhtmlcount2.htm

I have the script working but wanted to implement a certain Time Zone to the countdown.

I have something that is going to end on June 6, 2005 23:59:59 EST and did not know how to make the countdown end at the Eastern Standard Time Zone?

Thanks in advance.

Thomas

[jscheuer1]

Hope you haven't given up yet or your event has passed by the time you see this. Anyways, the script you are using uses the time as set on the user's computer. As is, that will return the time left until the time of your event as if it were occurring locally for the user. For many televised events, this is better than EST, also, by June 6th we may have daylight time to worry about as well. Local time of the user may be daylight or not depending upon convention in his/her zone. If you still want to go for EST, even though it will be EDT by then, I think. You can follow this line in the code:

var todayh=today.getHours()

with:

if ('number'==typeof today.getUTCHours()){ todayh=today.getUTCHours()-5;todayd=today.getUTCDate();
if (todayh<0) {todayh=todayh+24; todayd=todayd-1;}}

This will give us the hour in Universal Time (if available) -5 (EST), use -4 for an event in daylight time, but since it may now be the previous day, a little more work is needed. That explains the second added line. If UTC time is not available, the user will get the calculation based upon his/her local time.

[thomas]

Thank You for your help! I will add the new code and see what happens! Thanks again.

PS - I used a -4 since Daylight Savings time is tomorrow night and my event will be in June. Sound ok?

[jscheuer1]

Originally Posted by thomas

I used a -4 since Daylight Savings time is tomorrow night and my event will be in June. Sound ok?

Yes sir! That's why I put that in. UTC time never varies for Daylight time. When I originally wrote on this, the time change was so far in the future I wasn't clear on when it would be. June 6th definitely is Daylight time. And since, as I said, UTC time never varies, it makes no difference what the current Eastern time is, only what it will be when the event occurs.

[mwinter]

Originally Posted by jscheuer1

if ('number'==typeof today.getUTCHours()){

If you're attempting to check that the getUTCHours method is supported, that isn't the way to go about it. You need to check that the method itself is available, not that it's return value is correct. If a host doesn't support a function, the script will error out - precisely what you should be trying to avoid.

In this instance,

if(today.getUTCHours) {

would be sufficient. However, I really don't believe it's necessary. The UTC methods have been supported since fourth generation browsers, and they're obsolete as it is.

By the way, constructing strings and using the parse method is a really obtuse way of doing this. Subtracting Date objects directly will result in the same millisecond value and is far more efficient.

function countdown() {
  var est    = new Date(),
      target = new Date(yr, mo, da, hr, min, sec);

  est.setUTCHours(est.getUTCHours - 5);
  dd = target - est;
  /* ... */
}

Untested, but I don't see how it would behave any differently.

Mike

[jscheuer1]

Originally Posted by mwinter

if(today.getUTCHours) {

Cool! I really don't understand your use of set in the altered countdown function, must look it up when I get a chance. One thing, I noticed you created est=new Date(), not sure if it matters but, we don't know what time zone the user is in.

Added Later, I put your code in where it looked like it went and got:

NaN days, NaN hours, NaN minutes, and NaN seconds left until Bulls vs Lakers game

[mwinter]

Originally Posted by jscheuer1

Cool! I really don't understand your use of set in the altered countdown function [...]

It depends why you're confused. The statement should actually read:

est.setUTCHours(est.getUTCHours() - 5);

Notice the function call now. This corrects the NaN problem.

With any of the Date manipulation methods, including the constructor itself, you can supply out-of-range values. When you do, the object will automatically cap the value, but adjust other fields too. For example, setting the 31st of November will result in a date of the 1st of December.

One thing, I noticed you created est=new Date(), not sure if it matters but, we don't know what time zone the user is in.

Well, it will start off at local time, but it will be set to -0500 (EST) by the setUTCHours call later.

I put your code in where it looked like it went and got [rubbish]

As I said above: correct the missing call and you should have no problems.

Mike

[jscheuer1]

Nice to know you sometimes mess up, like the rest of us, I was starting to get a complex. Anyways, your new modification makes it better, no NAN's. However, my version and the original version give 71 days to June 12th 2005, your code makes it 101 days. 71 is the correct amount as I type, according to a calendar. Off by a month, probably a simple fix for that.

[mwinter]

Originally Posted by jscheuer1

Nice to know you sometimes mess up, like the rest of us [...]

We're all human. I've made plenty of monumental cock-ups in the past, I can assure you. Hopefully, they'll stay in the past.

Off by a month, probably a simple fix for that.

The month ordinal scheme for ECMAScript dates is zero-based (0 => January, 1 => February, etc.) Clearly, the script is one-based (it would be nice if that was mentioned in the script description, though I should have looked at the code more closely). Subtract one in the constructor call:

var est    = new Date(),
    target = new Date(yr, mo - 1, da, hr, min, sec);

Mike

[jscheuer1]

Originally Posted by mwinter

Subtract one in the constructor call

Yeah, I just figured that out. One other problem is that in order to get the hours correct it needs to be:

function countdown() {
  var est    = new Date(),
      target = new Date(yr, mo-1, da, hr, min, sec);

  est.setUTCHours(est.getUTCHours()+1);
  dd = target - est;

for an event in daylight time (no adjustment for standard time), since I am in the EST zone, that leads me to believe you either have not broken out of the user's local time zone, or have done so redundantly with your original code.