Closed centralhardware closed 9 months ago
the problem is that the device that transmits the coordinates may be in a time zone that is different from the server’s time zone
For now i am identify timezone by reverse geocoding but if i can receive timezone directly from device it made everything easier
You raise a very valid point.
When using our Recorder as backend, we perform reverse geo lookups (if so configured), and store country code alongside the address in the LMDB database:
$ ocat —dump | grep …
u0fxp88 {"cc":"BE","addr":"Autoroute de Wallonie, 7390 Mons, Belgium","tst":1660297060,"locality":"Mons"}
This data is surfaced via the API:
curl http://192.168.1.30:8083/api/0/locations -d
user=jp -d device=5s -d from=2022-08-12T06:50 -d format=json | jq .
{
"_type": "location",
"acc": 5,
"lat": 50.453064,
"lon": 3.845614,
"tid": "jp",
"tst": 1660297031,
"vac": 3, "vel": 116,
"ghash": "u0fxp88",
"cc": "BE",
"addr": "Autoroute de Wallonie, 7390 Mons, Belgium",
"locality": "Mons",
"isorcv": "2022-08-12T09:37:11Z",
"isotst": "2022-08-12T09:37:11Z",
"disptst": "2022-08-12 09:37:11"
}
and, finally, that contains a country code (cc
).
It’s not exactly what you want, but might be a bit of help. However, we’d need to take tst
into consideration to determine whether daylight savings was in effect, etc.
What a mess. ;)
We've been talking about this. The tst
is definitely in UTC. As @ckrey points out it is possible to lookup $TZ
using one of a large number of languages / services
Solved by #444 Many thanks to the participants for their useful help
not specifically, but. you might be able to use os.date.