Facebook api doesn't return information if the range of time is set before 1 january 2017? For example, i make this request {profile_id}/posts?since=1480543200&until=1483135200 and I recieved nothing, even an error.
This request supposed to give me all the posts of the profile between December 1 and 31 December 2016. I do something wrong? If I make a similar request, but i set as time range a date from 2017 and everythings it's going well. Thanks!
it's a facebook bug.
and it's fixed.
https://developers.facebook.com/bugs/2297783020445879/
me/posts?since=1480543200&until=1483135200
or
me/posts?since=2017-01-01&until=2017-12-31
Related
Using Power Query to query Kusto and the query times out after 5 minutes even though I've set the timeout to 21 minutes, like this:
[Timeout = #duration(0,0,21,0), ClientRequestProperties = [#"query_language" = "csl"]])
The query in question typically takes about 7-10 minutes when run directly in Kusto.
A similar question asked here had an answer that suggested going to "Data source settings" and clicking on "Change Source..." but that button is grayed for me. Besides, the above, query-specific setting should override a global setting, right?
Assuming that you're using the AzureDataExplorer.Contents() or Kusto.Contents() methods, there was a regression in the Timeout implementations of the connector. This was fixed on Jun 7 2021, and should be included in version 3.0.52 of the connector (should already be publicly available - make sure you have the latest version of the PBI Desktop).
If you're still facing an issue, contact me directly at itsagui(at)microsoft.com
When I open up Developer Tools in Chrome, I see cookies that expire in 1969. Shouldn't the browser delete them? I thought the way to delete a cookie was to set the expiration date to a date in the past?
I'm not 100% sure, but after talking this over with a coworker, this is what I think is happening:
Unix keeps track of time using the number of seconds passed since 1 January 1970. This number is stored as a signed 32-bit binary integer. (On a side note, this means that Unix will run out of time in 2038, but I digress...)
Since Unix time was started on January, 1 1970, -1 is in December 31, 1969, 11:59:59pm. Apparently, -1 is a commonly used value for "unknown" if the expected value is usually positive. Cookies which have a negative MaxAge means that the cookie is not stored persistently and will be deleted when the Web browser exits.
We have a web server running Windows 2003 Standard and the time zone is set to GMT-06:00 Central Time, and the box is checked to adjust for daylight saving changes.
A web service on this server queries a datetime field and when the datetime is fetched it is correct. When the dataset is returned to the client 1 hour is subtracted from the datetime if the date is Mar 9-31, Apr 1-5, Oct 26-31, or Nov 1-5. These are the dates that the DST time change can happen on.
It does not matter when the data was saved to the database. If I save a date of 4/1/2013 today, it will be returned to the client minus the 1 hour.
We have verified that SQL is storing the date correctly since it is being returned to the web service correctly.
If I convert the date to a date string at the web server before returning it to the client, the correct date string is returned.
All dates outside of the possible DST dates are good.
All dates during DST that are not on a possible change date are good.
As an example, a date saved as 4/1/2013 12:00:00 AM will be returned as 3/31/2013 11:00:00 PM.
A date saved as 4/6/2013 12:00:00 AM will be returned as 4/6/2013 12:00:00 AM.
I added a web method to the web server to return a date value of Now() and it returns the correct date.
The only thing I have found that is similar was something about a XML rule that says all datetime values are to be transmitted using an offset. I'm not 100% sure but I don't think this is it because only some dates are changed.
Any thoughts/suggestions of what else to look at to get this resolved?
Edit: I have found some dates on the dates listed above that are correct.
I'm going to take a shot at expanding this question, since i've had a similar issue in serialization of data objects.
Take a System.DateTime object that you want to write into a DataColumn. The DateTime object will by default return the DateTime.Kind property as [Unspecified]. When the DataColumn is then set to this DateTime object the DataColumn has a DateTimeMode property that resets to [UnspecifiedLocal].
There is not offest during serialization of DataColumn when the DateTimeMode is [Unspecified] or [UTC]. But when the DateTimeMode is set to [UnspecifiedLocal] or [Local], the offeset is applied. This is where the time can go up or down depending on the timezone or daylight savings configuration.
Sad news is that I can share your problem, but don't have a decent solution. Hope this helps your search.
I can only think of some ugly solutions, but i have not tested any. If i find an elegant solution i will try post again.
I am trying to add Events To FaceBook with the Time Zone option enabled. I am trying to add Events in UK with time zone as "Europe/London" . This is what I am noticing.
When I send the following Start & End times
[start_time] => 2014-08-24T20:00:00+0100
[end_time] => 2014-08-24T22:00:00+0100
I get the time as
[When]
Sunday, August 24, 2014
[Time]
8:00pm until 10:00pm
when viewed from FaceBook Site. My time zone is set to London which is UTC. But when I send an event in November,
[start_time] => 2014-11-24T20:00:00+0000
[end_time] => 2014-11-24T22:00:00+0000
it is getting displayed as
[When]
Monday, November 24, 2014
[Time]
9:00pm until 11:00pm
Is this an expected behavior. Will the time be adjusted and 8 PM will show correctly on Nov 24th?
Thanks
Lynn
One small correction. You said:
My time zone is set to London which is UTC
The Europe/London zone is UTC+00:00 in the winter, which is commonly called GMT. In the summer it switches to UTC+01:00. which is commonly called BST. It wouldn't be accurate to say that London is UTC. I think you knew this already, I'm just stating it here for others.
Unfortunately, the behavior you describe is expected for Facebook. It comes down to the fact that Facebook doesn't know you are in Europe/London. It simply gets your current time zone offset from JavaScript's new Date().getTimezoneOffset() when you log in. Since it's currently UTC+01:00, that's the offset that is applied to the events when you view the page as a user. It makes a flawed assumption that the offset will not change, or that you won't be looking at future event times until after the next transition.
The Facebook Graph API represents this in the user object. It has a timezone property that is just a number. I guess the Facebook developers haven't read the timezone tag wiki where I make clear that "Time Zone != Offset".
Will the time be adjusted and 8 PM will show correctly on Nov 24th?
Yes. It will show the correct time as soon as the user logs in after the next switch from BST to GMT, which is on October 27th this year.
From the last few days, Facebook insights API is giving Fan count as 0 for certain dates and when queried for Fan count for the same dates after few days, insights API is giving the count. Is there a bug with insights API for this abnormal behaviour?
Insights API used to work without any issues so far and from the past 15 days or so I have noticed this abnormal behavior.
Please help regarding this if any one has any idea about this abnormal behavior.
Thank you,
Raghu
I have also this bug too, additionally for the other metrics deprecated as said in FB. Two days before I could get page_fans for January 3-5,2012 but after 10 minutes of that it was gone !
Also I noticed that in the queries in FB.api we wrote, end_time has to be written like a UNIX time ie 12423492349 not like 2011-01-03 in this function. I think this end_time function becomes a bug for the API and now there is no of that.