AHP 3.177 ignores seconds when setting CM11A clock.

[Charles Sullivan]

AHP ignores the seconds when setting the
CM11A clock, so the clock may differ from
system time by up to 59 seconds.  Downloaded
timed macros will therefore execute late by
that time discrepancy.  As far as I can tell,
this bug was introduced in AHP 3.175, and it
persists in 3.177.

This is just one more PITA stumbling block
which interferes with proper testing of AHP.  

[X10 Pro]

I've just confirmed that this change is
deliberate, and not something we're going to
be changing back.

[Noam]

X10 - Any explanation for WHY it was
changed?

[Mike C]

I would like to know why as well?

[coder since cp290]

As providing seconds is just another field
when setting the time (same message back to
the cm15a), I cant quite see why it won't be
sent, or more correctly, sent with the right
value.  Seconds ARE being sent, but they just
happen to always be zero!

The reality is that it probably doesn't
matter much in the long term, as when the
CM15a is stable enough that people just "let
it run" the clock drift could be seconds per
day/week anyway.  Just like a PC's clock
(unless you're running NTP)

[roger1818]

That is one thing I can't understand.  Why
can you buy a $5 digital watch which keeps
acurate time for months, yet the clock in a
$1000 PC drifts badly.

[Charles Sullivan]

Unfortunately my experience tells me that
when a change like this is made, it's to help
conceal a major design bug from the average
user.