Incorrect timestamp in tst about gw HOT 25 CLOSED

I experienced the same problem.

Owntracks on IOS shows the latest position only, So when this happens, it seems as if the gw is no longer sending updates.

Will have a look

from gw.

I noticed two updates with different speed (spd) and (alt) elements, so the device was doing something ...

from gw.

do you have the raw data too? ($set raw=1)

from gw.

raw now enabled; if I notice it happening again, I'll yell. (But you know where I'm publishing to...)

from gw.

I've caught this again, with raw data. It may be a coincidence, but this happens when the clock ticks over into a new day:

$CHX,GWBUS-ak,A,09,140731,235815,5202.06815,
{"_type":"location","t":"t","tst":"1406851095",
    == Fri Aug  1 01:58:15 2014


$CHX,GWBUS-ak,A,09,140801,000015,5202.06523,
{"_type":"location","t":"t","tst":"1406894415",
    == Fri Aug  1 14:00:15 2014

from gw.

anything related to auto reboot of the module (Matteo)?

from gw.

Doubtful, @bluewindthings, because the NMEA timestamp is correct; it seems to me to be a conversion thing within our code.

from gw.

ok

from gw.

Yes, I think it is a conversion bug

from gw.

It seems that the hours result is: correct hours+years.
In the first case 08 + 14.
In the second case 00 + 14.
Could it be?

from gw.

I guess it is the conversion. Not obvious, but I'll find out!

Thanks for searching

from gw.

can't reproduce in unit test, probably side effects...

from gw.

Side effects eliminated

from gw.

Issue seen again per chance on your device this morning.

$CHX,356612027383852,A,07,140804,075336,

owntracks/gw/356612027383852 {"_type":"location","t":"t","tst":"1407182016"

    => Mon Aug  4 21:53:36 2014

from gw.

ok, I won't trust java's calendar (am/pm/utc) implementation anymore. I'll do it on my own.
Think I still have some 33 years old basic code for that purpose.

from gw.

Another, in case this helps finding the issue:

owntracks/GWBUS-ak/raw $CHX,GWBUS-ak,A,07,140805,042046,5202.06164,N
owntracks/GWBUS-ak {"_type":"location","t":"t","tst":"1407255646",

   => Tue Aug  5 18:20:46 2014

from gw.

fixed with homegrown code in DateParser.java

from gw.

Sorry, but this isn't quite right yet:

From your device this morning:

$CHX,356612027383852,A,09,140806,084557,
{"_type":"location","t":"t","tst":"1407401157"

  => Thu Aug  7 10:45:57 2014

One day in the future.

from gw.

And yeah, I am a pain, eh? ;-)

from gw.

Could it be UTC/GMT time in this case?

from gw.

No, sorry, also the day is wrong

from gw.

No. It's 24h off.

from gw.

Ok, will fix on friday, and yes timestamp is UTC

from gw.

I have committed but not pushed the last version to github

from gw.

Fixed in 0.3.79 (day string with 1, not 0)

from gw.