I'm intending to use the realtime clock on the WiFly bee and all's well, but the value of RTC, which I parse from this output here into a long,
<2.32> show t t
...and then use the time library function setTime(RTCvalue)
. But this sets the time to be precisely 2 hours ahead of the real world, despite the time output in human readable form (as per above) being accurate. I can fix this with a
but would be far happier doing so if I understood why. It does seem like a kludge, especially when to get the Time= value accurate, I've set the WiFly bee up with
set time zone 14
This was found with trial and error, since I'm in the UTC+10 timezone. I don't understand how the zone number works, since from the WiFly manual (p48) it states :
The default sNTP server is at
ZONE=7 (GMT -7)
which you'd presume should be ZONE=-
7. I've put a ticket into Roving Networks to see if they can point me to an explanation. Certainly Zone -10 makes the Time= value well wrong (presently at 21:49, the WiFly reports the time as 45:49 if I set the zone to -10, and 01:49 if I set it to 10, but the correct time with the zone set to 14.
So in summary : when the time is displayed correctly by the WiFly (Zone = 14), the RTC value is out by 2 hours for UTC+10. Can anyone give me an idea why that might be? And does it matter, or should I just put the adjustTime() line in the sketch and move on quietly?