Help with check time function

[D]

Hello all...I have an issue with one of my java script functions that
I'm hoping someone can easily help with. I have a web based application

that we use to create/sign up for overtime. When we have holidays we
require our employees to sign up in 4 hr increments for the times we
post. I'm having trouble creating a time slot that ends @ 12am. 12pm
and all other hours work fine for start/end times. however 12am causes
problems. My actual script code for this function is below. Someone
help!!!

<SCRIPT language="JavaScript" src="frmvalidation.js"
type="text/JavaScript"></SCRIPT>
<script language="javascript">
function checkValidHoliday(value)
{


if (value=='Y'){
hourblock.style.visibility ='visible';
}
else{
hourblock.style.visibility ='hidden';
}
}


function checkHoliday(frm)
{


if(frm.txtIsHoliday.value=="Y")
{
strFromDt= new Date(frm.txtLimitDate.value);
strToDt= new Date(frm.txtLimitToDate.value);
FromHr=parseInt(frm.txtLimitFrom.value);
FromAMPM=frm.txtLimitFromAM_PM.value;
ToHr=parseInt(frm.txtLimitTo.value);
ToAMPM=frm.txtLimitToAM_PM.value;


if((FromAMPM=="PM") && (FromHr!=12))
FromHr=FromHr+12;


if((ToAMPM=="PM") && (ToHr!=12))
ToHr=ToHr+12;


var fromDt= new
Date(strFromDt.getFullYear(),strFromDt.getMonth(),strFromDt.getDate(),FromH­r,0);

var toDt= new
Date(strToDt.getFullYear(),strToDt.getMonth(),strToDt.getDate(),ToHr,0);

//alert(toDt + " " + fromDt);
//alert(FromHr + " " +ToHr);


var
HolidayBlock=(parseInt(frm.cboHolidayHours.value) * 360 * 10000)
;
//alert((toDt-fromDt) + " " + HolidayBlock );


if((toDt-fromDt)== HolidayBlock)//14400000)
return true;
else
{
alert("Please select "+
parseInt(frm.cboHolidayHours.value) +" Hour
Block only for Holiday!");
frm.txtLimitFrom.focus();
return false;
}
}
return true;
}
</script>

 

[RobG]

Hello all...I have an issue with one of my java script functions that
I'm hoping someone can easily help with. I have a web based application

that we use to create/sign up for overtime. When we have holidays we
require our employees to sign up in 4 hr increments for the times we
post. I'm having trouble creating a time slot that ends @ 12am. 12pm
and all other hours work fine for start/end times. however 12am causes
problems. My actual script code for this function is below. Someone
help!!!

I guess what you call a "slot" ending at 12am is something like 8pm to
midnight. I suspect the reall issue isn't creating the slot, but how
to display it so a user sees 8pm to midnight on a particular date,
rather than 8pm to 12am the following day.

I find the use of 12am and 12pm confusing, though I think most people
consider 12pm is noon and 12am is midnight. You could replace them with
noon/midday and midnight or use a 24hr clock, though without seeing
your screen layout I'm only guessing.

How you handle the 'real' time behind the scenes is up to you, but you
need to make it simple for people to select a date, then a time slot.
You could get the date by subtracting one second from the "to" time,
then use that date. For midnight, it will give you the date of the
preceeding day (i.e. the one before 00hrs). For all other "to" times,
it will give you the same day (assuming 4 hours slots).

<SCRIPT language="JavaScript" src="frmvalidation.js"
type="text/JavaScript"></SCRIPT>

The language attribute is deprecated, you can remove it. Keep type.
It doesn't make much sense to post a script element that references a
script file we can't access.

<script language="javascript">
function checkValidHoliday(value)
{

Please indent using 2 or 4 spaces, it reduces wrapping. Also, this
function is not called by your script, so not much point in including
it.

[...]

function checkHoliday(frm)
{
if(frm.txtIsHoliday.value=="Y")

That form control seems to be either a select or a text input, consider
using a checkbox:

<label for="txtIsHoliday"><input type="checkbox" id="txtIsHoliday"
name="txtIsHoliday">Is this for a holiday?</label>

Now you can use:

if (frm.txtIsHoliday.checked)

{
strFromDt= new Date(frm.txtLimitDate.value);
strToDt= new Date(frm.txtLimitToDate.value);
FromHr=parseInt(frm.txtLimitFrom.value);
FromAMPM=frm.txtLimitFromAM_PM.value;
ToHr=parseInt(frm.txtLimitTo.value);
ToAMPM=frm.txtLimitToAM_PM.value;

Why all the global variables? You should keep them local unless you
have a good reason for them to be global. You may have conflicts with
variables used in other (not posted) functions.

You also haven't posted anything to let us know what the values are.
If any are user-entered, you must validate them first. I'll presume
they are all selected from selects and you know they'll be OK.

if((FromAMPM=="PM") && (FromHr!=12))
FromHr=FromHr+12;

I guess these are all values selected from select elements, and that
you have one for am/pm and one for 0 to 12 hours. Why not use one
select with the text as four hourly intervals (or hourly if it's used
for other things too) from 0 am through noon to 12 midnight. Then set
the values using a 24 hour clock, e.g.

<select name="fromHr">
<option value="0">0 am (midnight)
<option value="4">4 am
<option value="8">8 am
<option value="12">12 noon
<option value="16">4 pm
<option value="20">8 pm
</select>
<select name="toHr">
<option value="4">4 am
<option value="8">8 am
<option value="12">12 noon
<option value="16">4 pm
<option value="20">8 pm
<option value="24">12 midnight
</select>


I find that less confusing, there is no need to select am/pm and
there's no conversion to 24hr clock. You need to validate the input to
ensure fromHr is before toHr (or deal with it some other way).

if((ToAMPM=="PM") && (ToHr!=12))
ToHr=ToHr+12;


var fromDt= new
Date(strFromDt.getFullYear(),strFromDt.getMonth(),strFromDt.getDate(),FromH­r,0);

var toDt= new
Date(strToDt.getFullYear(),strToDt.getMonth(),strToDt.getDate(),ToHr,0);

//alert(toDt + " " + fromDt);
//alert(FromHr + " " +ToHr);


var
HolidayBlock=(parseInt(frm.cboHolidayHours.value) * 360 * 10000)
;

If you are converting from hours to milliseconds, the relevant values
are 3600 (seconds per hour) and 1000 (milliseconds per second) - your
values will end up with the right multiplier, but the individual values
are wrong. There is no need to use parseInt when multiplying a string
that (I guess) you know will have a suitable value, it will be
converted to a number by the multiplication. You might find it easier
to use 3.6e6.

var HolidayBlock = frm.cboHolidayHours.value * 3.6e6;


Again, we have no idea what the value of HolidayBlock is - I'll guess
that it's "4".

//alert((toDt-fromDt) + " " + HolidayBlock );


if((toDt-fromDt)== HolidayBlock)//14400000)
return true;
else
{
alert("Please select "+
parseInt(frm.cboHolidayHours.value) +" Hour

It seems you are getting the value of a form control, which is a
string, using parseInt (unnecessarily) to convert it to a number, then
concatenating it to a string which will convert it back to a string.
Why bother with the conversion? There is also no need for the else
part - if the preceding if statement returns true, the function will
return and the following statement will not be executed.

Block only for Holiday!");
frm.txtLimitFrom.focus();
return false;
}
}
return true;

Why not start the script with:

if ( ! frm.txtIsHoliday.checked) return true;

and get rid of the outer if block.

Does your script deal effectively with changes to/from daylight saving?
Your explicit use of a four hour interval in milliseconds makes me
think it doesn't.

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Mon, 28 Aug 2006 14:10:10 remote, seen in

Hello all...I have an issue with one of my java script functions that
I'm hoping someone can easily help with. I have a web based application

that we use to create/sign up for overtime. When we have holidays we
require our employees to sign up in 4 hr increments for the times we
post. I'm having trouble creating a time slot that ends @ 12am. 12pm
and all other hours work fine for start/end times. however 12am causes
problems. My actual script code for this function is below. Someone
help!!!

Unless you employ morons, don't use the 12-hour clock in data
processing.

<SCRIPT language="JavaScript" src="frmvalidation.js"

^^^^^^^^^^^^^^^^^^^^^ superfluous

type="text/JavaScript"></SCRIPT>
<script language="javascript">
function checkValidHoliday(value)
{


if (value=='Y'){
hourblock.style.visibility ='visible';
}
else{
hourblock.style.visibility ='hidden';
}
}

hourblock.style.visibility = value=='Y' ? 'visible' : 'hidden'

function checkHoliday(frm)
{


if(frm.txtIsHoliday.value=="Y")
{
strFromDt= new Date(frm.txtLimitDate.value);
strToDt= new Date(frm.txtLimitToDate.value);

So what if they enter 9/31/06 ? Validate input dates. See below.

FromHr=parseInt(frm.txtLimitFrom.value);

So what if they enter "09" ?

FromAMPM=frm.txtLimitFromAM_PM.value;
ToHr=parseInt(frm.txtLimitTo.value);
ToAMPM=frm.txtLimitToAM_PM.value;


if((FromAMPM=="PM") && (FromHr!=12))
FromHr=FromHr+12;


if((ToAMPM=="PM") && (ToHr!=12))
ToHr=ToHr+12;


var fromDt= new
Date(strFromDt.getFullYear(),strFromDt.getMonth(),strFromDt.getDate(),FromH­r,0
)
;

Indentation should show structure. Therefore, posted code must not be
line-wrapped by the posting agent. Don't indent with tabs for News.

FromH? r?

IMHO better to use
fromDt = new Date(+strFromDt)
and adjust that with
setHour(getHour()-r)

var toDt= new
Date(strToDt.getFullYear(),strToDt.getMonth(),strToDt.getDate(),ToHr,0);

//alert(toDt + " " + fromDt);
//alert(FromHr + " " +ToHr);


var
HolidayBlock=(parseInt(frm.cboHolidayHours.value) * 360 * 10000)

3600 * 1000 would be more intelligent. But, as you work in exact hours,
why not use exact hours for arithmetic, rather than to milliseconds?

;
//alert((toDt-fromDt) + " " + HolidayBlock );


if((toDt-fromDt)== HolidayBlock)//14400000)
return true;

else cannot be needed after if... return true.

else
{
alert("Please select "+
parseInt(frm.cboHolidayHours.value) +" Hour
Block only for Holiday!");
frm.txtLimitFrom.focus();
return false;
}
}
return true;
}
</script>

You read two dates in similar form. This should be done by calling a
function which, given the field, e.g. frm.txtLimitDate, reads it,
validates it, deals with error, and returns a Date Object; and similarly
for time (or maybe given the fields handles both date & time).

Read the newsgroup FAQ. See below.

 

[D]

Hi Rob!
Wow! I didn't realize so much could be wrong, but never assume
right!? Unfortunately I don't have any of this on a public server, all
on local intranet. You are correct when stating my "slot" is 8pm -
12am. I believe this problem is a little deeper than originally
thought. I started to work a little more with overall functionality of
this application and discovered that any employee that actually signs
up for an 8pm - 12 am slot ( done on the physical d/b itself ) doesn't
register on the front end interface tool. Thanks for all of the info
Rob, this will greatly help with my trial/error process that I'm about
to embark on.

Hello all...I have an issue with one of my java script functions that
I'm hoping someone can easily help with. I have a web based application

that we use to create/sign up for overtime. When we have holidays we
require our employees to sign up in 4 hr increments for the times we
post. I'm having trouble creating a time slot that ends @ 12am. 12pm
and all other hours work fine for start/end times. however 12am causes
problems. My actual script code for this function is below. Someone
help!!!

I guess what you call a "slot" ending at 12am is something like 8pm to
midnight. I suspect the reall issue isn't creating the slot, but how
to display it so a user sees 8pm to midnight on a particular date,
rather than 8pm to 12am the following day.

I find the use of 12am and 12pm confusing, though I think most people
consider 12pm is noon and 12am is midnight. You could replace them with
noon/midday and midnight or use a 24hr clock, though without seeing
your screen layout I'm only guessing.

How you handle the 'real' time behind the scenes is up to you, but you
need to make it simple for people to select a date, then a time slot.
You could get the date by subtracting one second from the "to" time,
then use that date. For midnight, it will give you the date of the
preceeding day (i.e. the one before 00hrs). For all other "to" times,
it will give you the same day (assuming 4 hours slots).

<SCRIPT language="JavaScript" src="frmvalidation.js"
type="text/JavaScript"></SCRIPT>

The language attribute is deprecated, you can remove it. Keep type.
It doesn't make much sense to post a script element that references a
script file we can't access.

<script language="javascript">
function checkValidHoliday(value)
{

Please indent using 2 or 4 spaces, it reduces wrapping. Also, this
function is not called by your script, so not much point in including
it.

[...]

function checkHoliday(frm)
{
if(frm.txtIsHoliday.value=="Y")

That form control seems to be either a select or a text input, consider
using a checkbox:

<label for="txtIsHoliday"><input type="checkbox" id="txtIsHoliday"
name="txtIsHoliday">Is this for a holiday?</label>

Now you can use:

if (frm.txtIsHoliday.checked)

{
strFromDt= new Date(frm.txtLimitDate.value);
strToDt= new Date(frm.txtLimitToDate.value);
FromHr=parseInt(frm.txtLimitFrom.value);
FromAMPM=frm.txtLimitFromAM_PM.value;
ToHr=parseInt(frm.txtLimitTo.value);
ToAMPM=frm.txtLimitToAM_PM.value;

Why all the global variables? You should keep them local unless you
have a good reason for them to be global. You may have conflicts with
variables used in other (not posted) functions.

You also haven't posted anything to let us know what the values are.
If any are user-entered, you must validate them first. I'll presume
they are all selected from selects and you know they'll be OK.

if((FromAMPM=="PM") && (FromHr!=12))
FromHr=FromHr+12;

I guess these are all values selected from select elements, and that
you have one for am/pm and one for 0 to 12 hours. Why not use one
select with the text as four hourly intervals (or hourly if it's used
for other things too) from 0 am through noon to 12 midnight. Then set
the values using a 24 hour clock, e.g.

<select name="fromHr">
<option value="0">0 am (midnight)
<option value="4">4 am
<option value="8">8 am
<option value="12">12 noon
<option value="16">4 pm
<option value="20">8 pm
</select>
<select name="toHr">
<option value="4">4 am
<option value="8">8 am
<option value="12">12 noon
<option value="16">4 pm
<option value="20">8 pm
<option value="24">12 midnight
</select>


I find that less confusing, there is no need to select am/pm and
there's no conversion to 24hr clock. You need to validate the input to
ensure fromHr is before toHr (or deal with it some other way).

if((ToAMPM=="PM") && (ToHr!=12))
ToHr=ToHr+12;


var fromDt= new
Date(strFromDt.getFullYear(),strFromDt.getMonth(),strFromDt.getDate(),FromH­r,0);

var toDt= new
Date(strToDt.getFullYear(),strToDt.getMonth(),strToDt.getDate(),ToHr,0);

//alert(toDt + " " + fromDt);
//alert(FromHr + " " +ToHr);


var
HolidayBlock=(parseInt(frm.cboHolidayHours.value) * 360 * 10000)
;

If you are converting from hours to milliseconds, the relevant values
are 3600 (seconds per hour) and 1000 (milliseconds per second) - your
values will end up with the right multiplier, but the individual values
are wrong. There is no need to use parseInt when multiplying a string
that (I guess) you know will have a suitable value, it will be
converted to a number by the multiplication. You might find it easier
to use 3.6e6.

var HolidayBlock = frm.cboHolidayHours.value * 3.6e6;


Again, we have no idea what the value of HolidayBlock is - I'll guess
that it's "4".

//alert((toDt-fromDt) + " " + HolidayBlock );


if((toDt-fromDt)== HolidayBlock)//14400000)
return true;
else
{
alert("Please select "+
parseInt(frm.cboHolidayHours.value) +" Hour

It seems you are getting the value of a form control, which is a
string, using parseInt (unnecessarily) to convert it to a number, then
concatenating it to a string which will convert it back to a string.
Why bother with the conversion? There is also no need for the else
part - if the preceding if statement returns true, the function will
return and the following statement will not be executed.

Block only for Holiday!");
frm.txtLimitFrom.focus();
return false;
}
}
return true;

Why not start the script with:

if ( ! frm.txtIsHoliday.checked) return true;

and get rid of the outer if block.

Does your script deal effectively with changes to/from daylight saving?
Your explicit use of a four hour interval in milliseconds makes me
think it doesn't.

 

[Dr John Stockton]

JRS: In article <[email protected]>,
dated Mon, 28 Aug 2006 17:21:59 remote, seen in

Please indent using 2 or 4 spaces, it reduces wrapping. Also, this
function is not called by your script, so not much point in including
it.

Apparent prejudice against 3 <g>.
Posters of code SHOULD NOT let the posting agent wrap it.

<URL:http://www.merlyn.demon.co.uk/js-quick.htm> Indt button gives a
valid, good, but not perfect re-indentation result, using 2, on OP code.

You might find it easier
to use 3.6e6.

Or 36e6 to avoid the "damned dot".

Does your script deal effectively with changes to/from daylight saving?
Your explicit use of a four hour interval in milliseconds makes me
think it doesn't.

Or /vice versa/ - the Management probably think in civil time only, and
that code uses UTC.

The answer is perhaps to use our normal validation, etc., but with
new Date(Date.UTC(...)) instead of new Date(...) and elsewhere
using the UTC functions. UTC behaves in actuality like Civil Time
appears to behave for those who change the clocks then forget about it.

With Net-connected equipment, and radio-controlled clocks & watches - I
presume you have those in AU - fewer people will actually be aware of
the bi-yearly change. (Will 1907 be celebrated in 2007?)

Of course, the OP may live in a region that has no DST.

OP : read the newsgroup and its FAQ before again responding.

 

[RobG]

JRS: In article <[email protected]>,
dated Mon, 28 Aug 2006 17:21:59 remote, seen in


Apparent prejudice against 3 <g>.
Posters of code SHOULD NOT let the posting agent wrap it.

<URL:http://www.merlyn.demon.co.uk/js-quick.htm> Indt button gives a
valid, good, but not perfect re-indentation result, using 2, on OP code.



Or 36e6 to avoid the "damned dot".

Or 36e5 to avoid being out by a factor of 10

Or /vice versa/ - the Management probably think in civil time only, and
that code uses UTC.

I have learned to distrust "probably" - it is all too frequently
equivalent to "I have no idea about that, my guess is...".

The answer is perhaps to use our normal validation, etc., but with
new Date(Date.UTC(...)) instead of new Date(...) and elsewhere
using the UTC functions. UTC behaves in actuality like Civil Time
appears to behave for those who change the clocks then forget about it.

It depends on the scope of the application - if it's for a single
location, UTC may be overkill. The chage to/from DST normally occurs
early on a Sunday, which for most is a holiday but not for everyone -
in many Islamic countries, what western countries call Sunday is
effectively equivalent to Tuesday, their "weekend" is Thursday and
Friday.

The treatment of work shifts going over the DST change often results in
special conditions in wage agreements, and therefore any timesheet
system will need to deal with that. It will probably(!) require
special treatment for different workers even if they all work for the
same employer and may depend on individual contracts or awards. For
salried staff, it's usually irrelevant.

I don't have a diffinitive answer, I just wanted the OP to consider how
DST might affect whatever algorithm was chosen.

With Net-connected equipment, and radio-controlled clocks & watches - I
presume you have those in AU - fewer people will actually be aware of
the bi-yearly change. (Will 1907 be celebrated in 2007?)

Dunno, did anything of note happen in 1907 to make it worth
celebrating?

I think "radio-controlled clocks & watches" actually make things worse.
The clock for my mobile phone message system is in the same timezone
as me but in a state that has DST. The state in which I live does not,
so every year I have to deal with phone messages being 1 hour out of
sync. Adjoining jurisdictions often have different change over dates -
it is a fact of life and therefore must be dealt with.

Of course, the OP may live in a region that has no DST.

Happlily, I do.

Rather than daylight saving in summer, I'd rather have daylight wasting
in winter and do everything an hour later. Imagine the saving in
heating costs if everyone was tucked up cosy in bed for an extra hour,
instead of turning up the heat in the pre-dawn chill? The savings are
possibly much greater than those achieved by daylight saving in summer.

[...]

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Tue, 29 Aug 2006 17:22:56 remote, seen in

Dunno, did anything of note happen in 1907 to make it worth
celebrating?

William Willett, then of Petts Wood, a suburb of Bromley in Kent (now
virtually in London) proposed, in a leaflet, the introduction of Summer
Time, later considered by the House of Commons (1908).

<URL:http://www.merlyn.demon.co.uk/uksumtim.htm> refers.