search

jackd248 / temps

Simple menubar application based on Electron with actual weather information and forecast.
https://jackd248.github.io/temps/
MIT License
557 stars 71 forks source link

Problem with time fetching #14

Open happydemic opened 8 years ago

happydemic commented 8 years ago

Ubuntu 16.10 (Unity). I am seeing an intermittent undefined/NaN error with the time and date fetching (see picture): temps

Is this an API rate limit issue?

jackd248 commented 8 years ago

Looks like a more bigger problem then I thought. Could be hang out with some of the api calls. I will have a look.

marcogutama commented 8 years ago

Same problem. How can we fix that?

aguilera51284 commented 8 years ago

Same! :S

jackd248 commented 8 years ago

Fixed the problem for now. Like @bhdouglass said, the google maps timezone api has exceeded their limit of 2500 requests a day. I provided a API Key for this service and at all don't want to suggest, that every user has to get another api key for temps. So for now, this is a fallback if the limit is exceeded and you will have your own timezone information. Any ideas how to solve this workaround?

Sorry for having this troubles.

happydemic commented 8 years ago

I said it too in my original post! Thanks for the fix. The fallback works fine in v.6.2.

I haven't had a chance to look at the code, but if I understand you, Temps now falls back to system time information if the Google API returns an error.

I wonder if a sturdier approach would be to use system time info by default, and offer some options for users for whom it doesn't work (typically because they are monitoring the weather in a location different from their own). Most users can use system time without problems, and are using API queries they don't need and getting no benefit. On the other hand, users whose system time does not match their Temps weather location might prefer not to fall back; they might prefer to see no time rather than the wrong time.

If Temps time queries are currently only somewhat over Google's limit, then a temporary workaround would be to disable fetching time from the API by default. A checkbox could enable users to display local time in their Temps location, fetching it from the API using the built-in key (your key): "Display local time for selected location. Time may not display." So long as your user base is fairly small, that might be enough to keep the requests under the limit.

A true fix would be to create an expert option for users to supply a Google Maps Timezone API key if they want to: "Advanced: Supply API key to display local time for selected location." If no key is supplied, use system time.