Timezone field put in backwards?

What steps will reproduce the problem?
1. run smatool on Linux with verbose debug, and at the same moment
2. run Sunny Explorer downloading data on Windows with Snoopy Pro
3. Compare contents of time zone field, after the time field.

What is the expected output? What do you see instead?
I've made considerable headway into getting Adelaide's 1/2 hr timezone working 
(but I'm not far enough to raise an issue with it just yet), and noticed this 
while debugging:
Sunny Explorer: ... 1f 99 e4 4e 99 85 ...
smatool v0.15:  ... 1f 99 e4 4e 85 99 ...

Note I've simulated exactly the same epoch time here, but you get the point... 
The epoch time is Least-significant byte first in both applications, but 
smatool puts Most-significant byte first for the timezone offset, whereas Sunny 
Explorer keeps it Least-significant byte first.

What version of the product are you using? On what operating system?
0.15, Kubuntu 11.04, vs Win XP SP2

Please provide any additional information below.
I'm not sure what the significance of the timezone is, nor how badly things 
break if you get it wrong.  Come to think of it I can't see why you need to add 
1 to your time zone in seconds to arrive at the time zone offset, but that's 
what we seem to need to do :)

The offending lines in smatool.c in main() can be fixed as follows:
...
   case 26: // $TIMEZONE timezone in seconds
     fl[cc] = tzhex[0];     // 'fixed'
     fl[cc+1] = tzhex[1];   // 'fixed'
     //fl[cc] = tzhex[1];   // 'broken'
     //fl[cc+1] = tzhex[0]; // 'broken'
     cc+=2;
...

Original issue reported on code.google.com by djkammer...@gmail.com on 11 Dec 2011 at 2:22

nebgor / sma-bluetooth

Timezone field put in backwards? #56