time zone

[soup_or_power]

Hi
I have a requirement to compare the user entry for mm/dd/yy/HH/mm
(month, day, year, hour, minute) to the Easter Standard Time.
I am using the following script, but it is not giving the right answer.
Your kind help is appreciated. Thank you!


//this is what user enters
var gdate = new Date(f.year.value, f.month.value, f.day.value,
f.hour.value, f.min.value);
var EST_offset = -4
var num_msecs = gdate.getTime()+ gdate.getTimezoneOffset() * 60000
+ EST_offset *3600000;

//the current time of the desk top depends on location
var gdate2 = new Date();
var num_msecs2 = gdate2.getTime()+ gdate2.getTimezoneOffset() *
60000;
//we don't know the offset from GMT! What does getTimezoneOffset
return?

if (num_msecs < num_msecs2) {
alert("Schedule time has to be in the future");
return false;
}

 

[Mick White]

//we don't know the offset from GMT! What does getTimezoneOffset
return?

Local number of minutes that the client is offset(subtracted) from Zulu
Time.

West of Greenwich positive, East negative.
Mick

 

[soup_or_power]

Thanks Mick. What is zulu time ? This is how I ended up coding, for the
record

//Form date/time validation

//In the US, dst starts on the first sunday in april and ends on
the last
//sunday in october..

//the date of the 1st sunday in april is:

var curYear = new Date(); // get the year (or manually set it)
// set up the 1st of april of the chosen year
// remember months are zero based, so april = 3
var startDST = new Date(curYear.getFullYear(), 3, 1); // sets a
date to 1st of april
// use the day number of the week as an offset
// by subtracting from 7 (# days in week)
// and add to 1st
startDST.setDate(1 + 7 - startDST.getDay());


// set up last day of october
var endDST = new Date(curYear.getFullYear(), 9, 31);
// subtract the day number in week of last day to arrive at last
sunday in month
endDST.setDate(31 - endDST.getDay());


var gdate = new Date(f.year.value, f.month.value, f.day.value,
f.hour.value, f.min.value);
var tzoffset = -4;
if ( gdate < startDST || gdate > endDST )
tzoffset = -5;

var num_msecs = gdate.getTime();
var gdate2 = new Date();
var num_msecs2 = gdate2.getTime() + gdate.getTimezoneOffset() *
60000 + tzoffset*3600000;
//alert("diff=" + (num_msecs - num_msecs2)/(60000*60) + "offset=" +
gdate.getTimezoneOffset() + "tzoffset=" + tzoffset );
if (num_msecs < num_msecs2) {
alert("Schedule time has to be in the future");
return false;
}

 

[RobG]

Thanks Mick. What is zulu time ? This is how I ended up coding, for the
record

Your algorithm appears flawed.

The first issue is checking that the values entered by the user are
valid numbers and generate a valid date and time - hopefully you do that
elsewhere and just didn't show it.

The second issue is that you are dependent on the client's local system
settings for date, time, region and daylight saving being correct which
they likely aren't in a good percentage of cases.

The third issue is that daylight saving changes are made at 02:00am,
your algorithm assumes that the change happens at 00:00 AM.

Lastly, your algorithm for finding the first Sunday in April fails when
it falls on the 1st of April (2012).

I think you are better off to always do this stuff on the server.

//Form date/time validation

//In the US, dst starts on the first sunday in april and ends on
the last
//sunday in october..

//the date of the 1st sunday in april is:

var curYear = new Date(); // get the year (or manually set it)
// set up the 1st of april of the chosen year
// remember months are zero based, so april = 3
var startDST = new Date(curYear.getFullYear(), 3, 1); // sets a

var startDST = new Date(curYear.getFullYear(), 3, 1, 2);

date to 1st of april
// use the day number of the week as an offset
// by subtracting from 7 (# days in week)
// and add to 1st
startDST.setDate(1 + 7 - startDST.getDay());

var startDST = new Date(curYear.getFullYear(), 3, 1, 2 );
startDST.setDate( 1 + (7-d.getDay())%7 );

// set up last day of october
var endDST = new Date(curYear.getFullYear(), 9, 31);

var endDST = new Date(curYear.getFullYear(), 9, 31, 2);


[...]

 

[soup_or_power]

Your algorithm appears flawed.

The first issue is checking that the values entered by the user are
valid numbers and generate a valid date and time - hopefully you do that
elsewhere and just didn't show it.

The user picks the data from pull-down menus.

The second issue is that you are dependent on the client's local system
settings for date, time, region and daylight saving being correct which
they likely aren't in a good percentage of cases.

I don't understand what you mean. Our server is in EST zone.
The client/browser could be in any time zone. One way to handle this
is to inject a timezone offset into the session.

The third issue is that daylight saving changes are made at 02:00am,
your algorithm assumes that the change happens at 00:00 AM.

Thanks! I copied the code to determine DST from this group archives.

Lastly, your algorithm for finding the first Sunday in April fails when
it falls on the 1st of April (2012).

I think you are better off to always do this stuff on the server.



var startDST = new Date(curYear.getFullYear(), 3, 1, 2);




var startDST = new Date(curYear.getFullYear(), 3, 1, 2 );
startDST.setDate( 1 + (7-d.getDay())%7 );

What is d.getDay? 'Guess it is startDST.getDay()
Can we do something like this to figure out the first Sunday?
for(var i=1; i < 8; i++) {
var startDST = new Date(curYear.getFullYear(), 3, i, 2);
if (startDST.getDay() == 0) {
break;
}
}

// set up last day of october
var endDST = new Date(curYear.getFullYear(), 9, 31);

var endDST = new Date(curYear.getFullYear(), 9, 31, 2);


[...]

Thanks a million!

 

[Mick White]

Thanks Mick. What is zulu time ? This is how I ended up coding, for the
record Zulu time is GMT

//Form date/time validation

//In the US, dst starts on the first sunday in april and ends on
the last
//sunday in october..

//the date of the 1st sunday in april is:

var curYear = new Date(); // get the year (or manually set it)
// set up the 1st of april of the chosen year
// remember months are zero based, so april = 3
var startDST = new Date(curYear.getFullYear(), 3, 1); // sets a
date to 1st of april
// use the day number of the week as an offset
// by subtracting from 7 (# days in week)
// and add to 1st
startDST.setDate(1 + 7 - startDST.getDay());

startDST.setDate(1 + (7-startDST.getDay())%7)

// set up last day of october
var endDST = new Date(curYear.getFullYear(), 9, 31);
// subtract the day number in week of last day to arrive at last
sunday in month
endDST.setDate(31 - .getDay());

endDST.setDate(31 - endDST.getDay() + 7)%7);

Mick

 

[RobG]

The user picks the data from pull-down menus.

Hmm, for most users that is painful (i.e. I'm not fond of it), but it's
one way to solve the problem.

I don't understand what you mean. Our server is in EST zone.
The client/browser could be in any time zone. One way to handle this
is to inject a timezone offset into the session.

Yes, the client system could be set to anything - the location is
irrelevant. When you initialize gdate2, you accept the system time and
offset as accurate but you have no guarantee that it is.

You could send a time stamp from your server when the page loads and
create a local date object as the very first thing you do. Then keep
track of elapsed time so you always work in the one time system. It
should never be more than a few seconds out, or maybe a minute.

I can't comment on the robustness of that, if you consider malicious
users it may not be sufficient.

Thanks! I copied the code to determine DST from this group archives.

You need to be careful, not everything posted here is strictly kosher
(I'm as guilty as anyone of that :-x ).

As always, design test cases and test exhaustively. Changeover years
where DST starts on Sunday the 1st or 7th (2001, 2002, 2007, 2012) or
ends on the 25th or 31st (2004, 2009, 2010) plus times in the 'overlap'
would be very close to top of the list.

[...]

What is d.getDay? 'Guess it is startDST.getDay()

Ah, sorry, a leftover from my testing. Yes, d is startDST

Can we do something like this to figure out the first Sunday?
for(var i=1; i < 8; i++) {
var startDST = new Date(curYear.getFullYear(), 3, i, 2);
if (startDST.getDay() == 0) {
break;
}

Yes, but there's no need. The line I suggested is sufficient and more
concise. I have no idea which is faster, but in any case the difference
is probably undetectable without running the statements a few thousand
times.

A shorter version of the above algorithm is:

while ( startDST.getDay() != 0 ){
startDST.setDate( startDST.getDate() + 1);
}

But why use 2 lines when one will do? I can hear JRS muttering about
being paid by the yard...

The first line could be:

while ( startDST.getDay() ){

But some would consider that a maintenance hazard.

[...]

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Wed, 5 Oct 2005 14:02:37, seen in (e-mail address removed) posted :

var curYear = new Date(); // get the year (or manually set it)
// set up the 1st of april of the chosen year
// remember months are zero based, so april = 3
var startDST = new Date(curYear.getFullYear(), 3, 1); // sets a
date to 1st of april
// use the day number of the week as an offset
// by subtracting from 7 (# days in week)
// and add to 1st
startDST.setDate(1 + 7 - startDST.getDay());

The range of getDay() is 0..6. Therefore, according to you, DST can
start on April 2..8, and never on April 1. Try your code for the year
2001.

Note that DST changes are at 02:00 local extant time.

Code posted to Usenet should be executable, and so not wrapped by the
posting agent.

Read the FAQ; see below.

 

[Randy Webb]

RobG said the following on 10/6/2005 9:09 AM:

(e-mail address removed) wrote:




Yes, but there's no need. The line I suggested is sufficient and more
concise. I have no idea which is faster, but in any case the difference
is probably undetectable without running the statements a few thousand
times.

A shorter version of the above algorithm is:

while ( startDST.getDay() != 0 ){
startDST.setDate( startDST.getDate() + 1);
}

But why use 2 lines when one will do? I can hear JRS muttering about
being paid by the yard...

Readability and maintenance come before any consideration of
compactness, let people mutter but it will never change.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated
Thu, 6 Oct 2005 12:43:57, seen in Mick White

startDST.setDate(1 + (7-startDST.getDay())%7)

endDST.setDate(31 - endDST.getDay() + 7)%7);

Unnecessary arithmetic, even if correct, which the second cannot be.
One need only go back by the 0..6 days given by getDay() from the last
possible date. No need for mod 7 here.

Actually, after new Date(), setDate(2) will be just as accurate as your
inrtended code for startDST, and after the end of this Summer,
setDate(29) for endDST.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Thu, 6
Oct 2005 03:39:52, seen in RobG

The second issue is that you are dependent on the client's local system
settings for date, time, region and daylight saving being correct which
they likely aren't in a good percentage of cases.

No, he only needs (given correct coding) that the client's idea of UTC
is correct.

Assume that the user is here in London with everything perfectly set for
local use at 18:00 on Midsummer's day, and enters particular YMDhms to
compare with current EST, which AIUI is Sydney Time. Let him then
instantaneously travel to Auckland NZ (making all of the date, time,
region, and season incorrect). He instantly re-enters the same data,
and exactly the same calculation should be done, since the relationship
between YMDhms and the current time in Sydney is not affected by the
questioner's location.

Since the OP called for a Standard (winter) time, there is no call for
the summer time rules.

OTOH, I'm not sure that he's properly expressed what he really wants
yet.