I am making a weather app and need 7 day forecast. I have successfully parsed and implemented google weather api XML in my app but the problem is that Google Weather API returns the forecast information of four days including the current day. For example, if today were Saturday, Google Weather API would return the forecast information of today (Saturday), Sunday, Monday, and Tuesday.
Can I make google api return 7 day forecast? If not then is there another weather api that I can use to get that info? Please keep in mind this app is going to be sold globally so I need something that can forecast a user weather for 7 days no matter where in the world they are.
The reason I went with google is that bloody company is reliable and the chances of their servers going down are minimal.
You can take a look at this one, it isn't free but doesn't seem to be very expensive.
http://www.worldweatheronline.com/
I saw this one, but I'm not sure if it's global
http://graphical.weather.gov/xml/#xml_changes
Related
The API seems to be giving different values to the maps website.
Here is the front-end output for travelling between Manchester Airport and the London Eye.
Here's the API output
As you can see the numbers are close, but since they should both be calling the same thing, I'm confused as to the difference?
I need to use this to work out the time between close proximity places, so a couple of minutes matters here.
This is the api url I'm using:
https://dev.virtualearth.net/REST/v1/Routes/DistanceMatrix?origins=53.361881,-2.270841&destinations=51.49984,-0.124663&travelMode=driving&timeUnit=minute&distanceUnit=mi&key={insertkey}
Does anyone have any ideas what I'm doing wrong?
I have a SP 2013 that was migrated to SPO.
The problem is the Time Zone is Germany, migration take place in India, and I’m developing in Portugal.
So I have some dates 1 day head and others 1 behind consuming for on SPO Rest Api. But the dates are correct in the lists.
The source tenant is defined as 12H so as the target.
At this time I’m really confused, so kindly I’m asking for help on this.
Should I open a ticket? Someone had the same issue?
Solved by
moment(data).tz('Europe/Berlin').format('DD-MMMM-YYYY')
This seems to be a common enough problem that there are a lot of entries when one googles for help but nothing has helped me yet.
I am finding that the results provided by the REST API for estimated_steps are wildly different from those that appear in the device app.
I am running a fetch task for users via cron job on a PHP/Laravel app.
I'm using this https://developers.google.com/fit/scenarios/read-daily-step-total - estimated_steps to retrieve the step count.
Some days the data is correct. Some days its wildly different. For instance, on one given day, the REST API gives step count of 5661 while the app shows 11,108. Then there are six seven days when the stream is correct.
Has anyone faced this sort of behavior? I've tested for timezone differences, logged and analyzed the response json to see if i'm making some obvious mistake, but nope.
You may check this How do I get the same step count as the Google Fit app? documentation. Be noted that even when using the right data source, your step count may still be different from that of the Google Fit app.
This could be due to one of the following reasons:
On Wear, the Fit MicroApp when connected will display step counts queried on the phone and transferred over via the Wearable APIs. Other MicroApps accessing local-only data will only get watch steps. We are working on making this easier for developers.
Sometimes the step calculation code for the Google Fit app is updated with bug fixes before we are able to release the fixes to developers (which requires a Google Play Services release). We are also working on making it possible for developers to access fixes at the same time.
The Fit app uses a specific data source for steps and it adds some functionality (which can be seen on the documentation) on top of the default merged steps stream.
You can access the "estimated" steps stream as shown here:
derived:com.google.step_count.delta:com.google.android.gms:estimated_steps
Hope this helps!
I looked at the API documentation and it was not immediately apparent to me. Is it available via partner access?
Also, the default rolling average for sentiment seems to be 7 days. Is there an option to change this. One obvious way of doing this is parsing the firehose and some partners probably do that. I don't care for all that data or parsing it, in the unlikely scenario where I can get access to that.
The Sentiment data is only available to partners that license our API. Please touch base with us and let us know what you would like to do and about your paid product:
http://stocktwits.com/developers/contact
There currently is no option to change the rolling average, we have plans to add different time frames, as we agree this would be helpful.
We offer a financial sentiment API at Knowsis.
API docs are available here: http://knowsis.github.io
Facebook publishes announcements/reminders for day-specific events like birthdays. Does localization affect when these are seen?
For example, if my birthday is February 1st, would a friend in another time zone see the announcement starting at Feb 1 their local time, in my time zone, or at some other time zone (e.g. Greenwich mean)?
Any option seems to have drawbacks:
If announcements are based on local time, a friend who lives in India may see the announcement the morning of February 1st for him, but I'd get it in the evening of a previous day. Or if they lived in Japan they might not see it until the evening of Feb 1st, when it's already Feb 2nd for me.
If announcements are based on my local time then the friend may be confused about when my birthday actually is, as the announcement will show up for them for at least part of a different day.
For a birthday announcements these aren't very serious concerns; it's just an simple example to clarify the question
I think the question pretty much describes the dilemma, which has no good universal selection. In the birthday example, the problem is in the vague definition of “birthday”; it is a social convention more than anything else.
If you consider something more objective, like a “one-day offer” by a company, then it becomes even more obvious that the crucial issue is how things are defined. In global consideration, a company should define when the offer is valid (e.g., on a particular day in a particular timezone) and announce it accordingly.
The programming challenge is then to implement this properly. Mostly, it is a matter of making time references relative to a specific timezone, or the user’s timezone. These typically require different approaches: server-side vs. client-side. (The server timezone might not coincide with the intended timezone, but they should have a defined relationship.)