Recently I was in Germany for a few weeks. I noticed two issues with the Smartweather app: #1 - The values on the Dashboard (first screen of App) would not consistently display. The values would be blank on the Dashboard but if I clicked on the temperature, all the values were in the graph. I don’t know if the network latency, but I was on pretty good wifi (20MB down) and good enough for VOIP calls. The Dashboard only was correct a few times over the weeks.
#2 - When I clicked to see the detail, the times were shown in my local (phone) timezone for Germany (CET+1) instead of the Central time zone the station is in. IMHO the times show in the graphs should be the time zone of where the station is, not where ever the viewer happens to be. I only noticed this when it was showing temperatures peaking in early morning.
Apple IOS 11.3 (not sure of the exact level because I just updated to IOS 11.4.1)
I too noticed the time zone weather data is displayed in is the same as where the viewer is and not the time zone where the weather station is.
I live in the Pacific time zone and recently traveled to the Central time zone. All data from my weather station was displayed in Central time.
Like jay_kruemcke, I think weather data should be displayed in the time zone the station is in, not the time zone the viewer is in.
This is a no-win situation for WeatherFlow. On one hand, no matter where one is located, one can look at the current time and at the WeatherFlow application and see that the weather data is X minutes old. As suggested here, others want the station time the weather happened. My feeling is that the general public will want the time the way it is. No matter which way WeatherFlow does it, people are going to complain.
maybe a simple solution might be to add 1 line. Leave the time as is (being readers time) and add this one line saying local weather station time … this way a person can see how many hours difference there is … and evaluate better the result like bloody h*ll it hot there at noon … or gosh night temps are horrible … etc
Sorry, Gary, but I completely disagree with you. I think most purchasers of these weather instruments are not the general public but weather geeks who want accurate data from their sensors no matter where in the world they are viewing the data. Temporally related data such as this is only accurate if we know the actual sensor local time the data was recorded.
For WeatherFlow, they already know the location and time zone of the station. The WF app graphs use the local time and time zone of the device the graphs are being displayed on. It is a simple matter to subtract one from the other to adjust the display time or at least give an indication of the time difference between the viewers time and the station time. A switch could be added in settings to toggle the display between station time and viewer time. Or use Eric’s suggestion to display both.
I don’t agree.
If I go to weather.com or weatherunderground or even google the weather in a location, the answer is always provided in the context of the time zone at the weather location. This is consistent with the way the METARs and aviation weather works.
Presenting a remote location weather in the viewers time zone is inaccurate and wrong.
I don’t agree either, but I can see the situation in which WF are stuck between a rock and a hard place. Someone will be unhappy no matter what choice they make regarding time zone.
In the long term though I’m sure WF will address these issues once the focus on hardware has relaxed a little. A simple toggle in the settings allowing the user to choose which timezone to display the data in would certainly solve the problem!