PDA

View Full Version : DD Countdown Script II - Eastern Time Zone?



thomas
03-18-2005, 06:17 PM
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
03-20-2005, 11:07 PM
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
04-01-2005, 03:59 PM
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
04-01-2005, 05:29 PM
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
04-02-2005, 01:16 AM
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
04-02-2005, 05:09 AM
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
04-02-2005, 10:25 AM
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
04-02-2005, 05:42 PM
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
04-02-2005, 06:01 PM
Nice to know you sometimes mess up, like the rest of us [...]:D 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
04-02-2005, 06:28 PM
Subtract one in the constructor callYeah, 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.

mwinter
04-02-2005, 06:49 PM
One can fairly reliably[1] determine if a user is in DST themselves, but one cannot automatically check if DST is in effect in a remote timezone. The Date object doesn't give that kind of information.

If you know the precise rules for a locale, you could check if DST is effect for the UTC time given by a machine. If you don't know the rules, well then you're screwed. :) I don't know how DST works in the States, so I can't help you there.

Mike


[1] Window's DST rules for the UK, at least, are incorrect as it changes the system clock an hour late. Of course, more important considerations are an accurate system clock and the correct locale settings.

jscheuer1
04-02-2005, 08:05 PM
That's not what I meant. Time can be so confusing what with the different zones and the different conventions for Daylight time in different places. What I meant was that your code does not give the correct result. And that it is hard for me to tell here being in the EST zone weather the reason is:

1) You haven't broken free from local time

or:

2) Your code:
est.setUTCHours(est.getUTCHours() - 5);is redundant.

If #2 is the case, the fix is:
est.setUTCHours(est.getUTCHours());Right now I am leaning toward #2 on the theory that the UTCHours somehow get inserted seemlessly into est variable. There is a third possibility and I may reset my computer's clock to figure this out. The third would be that you are only updating local hours to UTCHours within the context of the local hours difference from the prime meridian. In any case lets stick with what works until we get this nailed down. I do like the simplicity your approach offers if it can be found to be reliable.

More problems could arise with users outside EST, as the target date is probably interpreted in local time. The extensive parsing out in the original code prevents all these convolutions.

mwinter
04-02-2005, 10:33 PM
You haven't broken free from local timeThat would be the case. Grrr. I hate date/time manipulation. :mad:

The Date constructor interprets its argument in local time; pretty much useless for a countdown. That's why I thought it would use UTC. The code needs to use the UTC method which returns a millisecond value representing that date. This value can then be passed to the single-argument constructor to create a useful Date object:


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

dd = target - now;This has two implications: 1) the target date must be UTC, and 2) as everything is performed in UTC, the timezone (of anyone) is irrelevant. Although it would only make sense to specify a UTC target time (an EST local time would be of little use to me here in the UK), it would now be compulsory.

Please tell me this is the end of this, now. :(

Mike

jscheuer1
04-02-2005, 10:56 PM
Please tell me this is the end of this, nowSure, I can mess with it if I want to, I think 'now' will have to be UTC'ized' as well but, I can figure that out. The fun part will be to find a way to have the developer using the script input what he/she understands (local time) for the event and have the result be relative to that in a meaningful way no matter where the user is located. That was the OP's original issue. That was resolved one way (as I originally advised him), perhaps this can be adapted to it but, you needn't worry about it.

mwinter
04-02-2005, 11:27 PM
I think 'now' will have to be UTC'ized' as wellThat's the odd thing; the Date constructor with no arguments (current time), or one argument (milliseconds since Epoch), creates an object set to UTC time, but local time with two or more arguments (specific year/month/etc. values).


The fun part will be to find a way to have the developer using the script input what he/she understands (local time) for the event and have the result be relative to that in a meaningful way no matter where the user is located.You could probably make a simple utility that asks for the time of the event. The utility could then provide some applicable output: perhaps a constructor call for the creation of a Date object. I think I'd prefer to tidy the original script up, then have a utility output a createCountdown call (or something like that).

Mike