[AirQuality] Handling timezones in JSON

[metbril]

I did some additional testing. Below you find logging data for 2 stations.

21:02:55.850 [DEBUG] [airquality.handler.AirQualityHandler] - aqiResponse = {"status":"ok","data":{"idx":3330,"aqi":3,"time":{"v":1485205200,"s":"2017-01-23 21:00:00","tz":"+03:00"},"city":{"name":"Spirid, Moscow","url":"http:\/\/aqicn.org\/city\/moscow\/spirid\/","geo":["55.7602761","37.5914501"]},"attributions":[{"name":"Moscow State environmental monitoring (\u0413\u043e\u0441\u0443\u0434\u0430\u0440\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u0439 \u044d\u043a\u043e\u043b\u043e\u0433\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 \u0432 \u041c\u043e\u0441\u043a\u0432\u0435)","url":"http:\/\/www.mosecom.ru\/air\/air-today\/"},{"name":"World Air Quality Index Project","url":"http:\/\/waqi.info\/"}],"iaqi":{"no2":{"v":14},"so2":{"v":0},"co":{"v":3},"t":{"v":-1},"d":{"v":-3},"p":{"v":1007},"h":{"v":86},"w":{"v":8}}}}
21:02:55.850 [DEBUG] [airquality.handler.AirQualityHandler] - aqiResponse = {"status":"ok","data":{"idx":5772,"aqi":120,"time":{"v":1485201600,"s":"2017-01-23 20:00:00","tz":"+01:00"},"city":{"name":"Rotterdam","url":"http:\/\/aqicn.org\/city\/rotterdam\/","geo":["51.93","4.47"]},"attributions":[{"name":"RIVM - Rijksinstituut voor Volksgezondheid en Milieum, Landelijk Meetnet Luchtkwaliteit","url":"http:\/\/www.luchtmeetnet.nl\/"},{"name":"World Air Quality Index Project","url":"http:\/\/waqi.info\/"}],"iaqi":{"pm25":{"v":120},"pm10":{"v":49},"o3":{"v":1},"no2":{"v":36},"t":{"v":2},"p":{"v":1026},"h":{"v":93}}}}

RTD: "time":{"v":1485201600,"s":"2017-01-23 20:00:00","tz":"+01:00"} MOW: "time":{"v":1485205200,"s":"2017-01-23 21:00:00","tz":"+03:00"}

The time for RTD is shown as 21:00 in the sitemap The time for MOW is shown as 22:00 in the sitemap

The latter can't be true, since this is logged at 21:02:55.850

So now the question is whether or not the times in the JSON are in GMT or local time. The API docs should make this clear.

http://aqicn.org/api/ / http://aqicn.org/json-api/doc/

Field	Type	Description
s	String	Local measurement time time.

So, perhaps the time does not need to be converted after all.

The timezone should be added to the date, to be able to present it local openHAB time.

My guess is, that RTD observation is 19:00 GMT and Moscow observation is 18:00 GMT. But I'm not sure.

[kubawolanin]

Hey Robert, thanks for continuing tests! I need to look at it more closely. After the fix I applied, the measurements in the binding are equal with what's stated on the website (yeah, the air is that bad where I live 😕 )

Do you have a timezone properly set on your device? Just asking because I didn't (that's why I didn't find this bug before you did 😉 )

[metbril]

$ date
ma 23 jan 2017 21:28:14 CET

[metbril]

I've added NYC to the mix:

21:40:32.994 [DEBUG] [airquality.handler.AirQualityHandler] - aqiResponse = {"status":"ok","data":{"idx":3309,"aqi":18,"time":{"v":1485180000,"s":"2017-01-23 14:00:00","tz":"-05:00"},"city":{"name":"New York","url":"http:\/\/aqicn.org\/city\/newyork\/","geo":["40.7127837","-74.0059413"]},"attributions":[{"name":"New York State Department of Environmental Conservation (NYSDEC)","url":"http:\/\/www.dec.ny.gov\/"},{"name":"Air Now - US EPA","url":"http:\/\/www.airnow.gov\/"},{"name":"World Air Quality Index Project","url":"http:\/\/waqi.info\/"}],"iaqi":{"pm25":{"v":18},"o3":{"v":22},"no2":{"v":10},"co":{"v":1},"t":{"v":4},"d":{"v":-1},"p":{"v":1005},"h":{"v":70},"w":{"v":10}}}}

NYC: "time":{"v":1485180000,"s":"2017-01-23 14:00:00","tz":"-05:00"}

I can only conclude that the time in the message is local time and that the time zone difference is stated:

EST (local time): 14:00 (GMT-5) GMT: 19:00 (EST+5) CET: 20:00 (GMT+1)

[metbril]

Help wanted from @ThomDietrich or @splatch?

[splatch]

@rtvb I saw your comment but didn't have time to verify it yet. If I understand correctly "s" is showing local time of place for which index is published. This means that we might need to do a little bit more dance than just using passed TZ. After gluing it we will just get GMT time which still may not be a local time.

[metbril]

As long as DateTime items get populated with a local time, it's just fine. I guess that computing GMT and returning it in the channel including the proper timezone ("Z") would suffice, don't you think?

[kubawolanin]

I decided to follow @rtvb advice and just display the "S" value as it is. I'll update JAR shortly in the main PR

[metbril]

That was not my advice. I meant MY local time, not that of the station. As far as I'm concerned I still consider this a bug since a DateTime item in OH is always considered to be in the time zone of the OH installation and NOT in any other time zone.