Re: Help with check time function

Dr John Stockton wrote:
JRS: In article <1156810919.306135.21440@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
dated Mon, 28 Aug 2006 17:21:59 remote, seen in
news:comp.lang.javascript, RobG <rgqld@xxxxxxxxxxxx> posted :

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".

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


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.

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 time***
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.

[...]

--
Rob

.