JRS: In article <
[email protected]>, dated
Fri, 3 Feb 2006 07:04:09 remote, seen in
Did you consider reading the newsgroup FAQ before posting? See sig
below.
Sorry, I did not. The reason is that I have absolutely *no*
prerequisite knowledge of HTML, JS, or C, and I don't foresee any
pressing need for same. In any case, I have two books on JS, but they
both assume a working knowledge of HTML.
Anyway I thought the answer would be simple enough, and indeed it was.
While it isn't pretty, here is my solution (using input from this NG):
http://www.users.on.net/~fzabkar/DSL-302G/TimeSync.htm
EAST is in fact not a time zone, AFAICS; a time zone is the set of all
places which have the same winter offset from GMT/UTC/UT. AIUI, the
Eastern third of Australia is in the GMT+10 zone, and remains in that
zone even in Summer when parts of it change their local time to GMT+11.
You appear to be in a part which has Summer Time.
You may need to send the Standard Time even in Summer, or you may need
to send the civil time. Timezone_combo is not to me an obvious concept.
I have no control over this because it is built into the modem's
firmware. In any case I don't consider timezone_combo as a true
variable because this setting can be saved in the modem's nonvolatile
memory. The user can preset his own choice in the abovementioned JS
script. Indeed, it would be impossible to programmatically select the
preferred timezone_combo given that some system time zones can map to
several timezone_combo options, eg:
20 CET +0100 Central European
21 FWT +0100 French Winter
22 MET +0100 Middle European
23 MEWT +0100 Middle European Winter
24 SWT +0100 Swedish Winter
You may want to consider the possibility of moving your system or giving
your code to a colleague elsewhere, in which case be sure not to hard-
code the local Time Rules.
This code is purely for my own convenience. The *only* reason that I
wish to synchronise the modem's date and time is so that I can make
sense of the modem's event log. I really don't care too much about the
time zone, or whether daylight is being saved. Therefore I am quite
happy to hard-code the TZ and DST parameters. In any case these
parameters can be retained by the modem's nonvolatile memory and need
not be updated.
Perhaps this log of PPP events will illustrate the problem:
http://www.users.on.net/~fzabkar/DSL-302G/Alarms.htm
Notice that when the modem first powers up and connects to the DSLAM,
the date and time are those which are retrieved from the modem's
nonvolatile memory:
======================================================================
Sat Sep 03 20:09:11 2005 : STATUS ALARM : ATM Interface Up : Interface
- atm-0
Sat Sep 03 20:09:11 2005 : STATUS ALARM : DSL Interface Up
Sat Sep 03 20:09:01 2005 : STATUS ALARM : System Up
======================================================================
I believe that "Sat Sep 03" was the date when I last saved the modem's
configuration settings, ie PPP, Bridging, LAN, WAN, Admin.
After synchronising the date/time, the log looks like this:
======================================================================
Sat Feb 04 19:02:42 2006 : STATUS ALARM : PPP Interface Up : Interface
- ppp-0
Sat Feb 04 19:02:42 2006 : STATUS ALARM: PPP Event: NCP Got secondary
DNS address: 192.231.203.3
Sat Feb 04 19:02:42 2006 : STATUS ALARM: PPP Event: NCP Got primary
DNS address: 192.231.203.132
======================================================================
Your PC is liable to indicate Winter Time from 2006-03-26, though AIUI
the change will be a week later.
A sensibly-designed router would want to be sent the time in ISO 8601
UTC format, i.e. as 2005-09-03 22:02:22Z ; presumably yours is imported
from a chronologically-inept location.
There's no difficulty in generating such a string from the information
in the Date Object D resulting from D = new Date() but your example
is not adequate to indicate the full requirement.
For example, does DST=1 mean that it *is* summer, or that the location
changes offset for summer. If the latter, how does it know when to
change offset - maybe DST rules are built in ... !!
Again, this is a function of the modem's firmware. It is of no real
interest to me as I don't work past midnight and I switch off the
modem when I'm done. I may experiment with this parameter, though,
just out of curiosity. When I find out how it works I'll add an
appropriate comment to the TimeSync routine.
Thanks for your input.
- Franc Zabkar