I used daily this request to googleapi in my application:
GET https://www.googleapis.com/youtube/v3/search?part=snippet&channelId={CHANNEL_ID}&maxResults=25&order=date&publishedAfter=2019-03-15T18%3A01%3A02.000Z&publishedBefore=2019-03-17T09%3A58%3A15.000Z&type=video&key={API_KEY}
Timestamps were of course changed each time. This worked fine till yesterday. Today this command did not work properly and returns results from different (much larger) time period.
Their timestamps are 25 and appear random:
"2018-10-04T10:06:56.000Z"
"2015-03-05T16:55:26.000Z"
"2018-09-24T08:05:59.000Z"
"2019-03-10T14:22:14.000Z"
"2018-07-24T19:08:39.000Z"
"2018-10-08T22:34:22.000Z"
"2018-09-10T11:38:37.000Z"
"2019-01-05T18:45:24.000Z"
"2019-02-12T07:00:07.000Z"
"2016-08-20T09:53:44.000Z"
"2018-10-20T21:31:43.000Z"
"2014-04-18T13:05:31.000Z"
"2019-01-24T14:00:30.000Z"
"2018-12-05T11:34:23.000Z"
"2019-03-04T13:59:05.000Z"
"2019-02-18T19:08:52.000Z"
"2018-12-24T11:33:56.000Z"
"2019-02-25T16:30:57.000Z"
"2017-07-07T16:44:59.000Z"
"2019-03-08T17:01:07.000Z"
"2019-02-04T12:49:42.000Z"
"2018-10-01T09:38:39.000Z"
"2015-09-18T22:52:30.000Z"
"2017-05-23T17:43:09.000Z"
"2019-03-13T17:59:24.000Z"
Is something broken?
Seems like it is a global problem.
https://support.google.com/youtube/thread/2494861?hl=en
Related
I want to test a simple strategy based on time: every day at fixed time check some conditions and go long. every day at fixed time exit.
Whatever I try to get timeOpenCondition I get syntax error.
Tried things similar to:
EntryTime = if hour=0800 and minute=0
ExitTime = if hour=1400 and minute=0
It feels like I don't get the concept of how this works. Appreciate any help!
I am using Carbon dates in my Laravel 8 project using PHP 7.
I recently came across a strange bug that occurring only on my production server and failed to execute locally.
I am sending an invite for the time set to timezone 'America/Sao_Paulo' which currently is operating over offset (-03:00), However, when I receive the email the timezone is rendered as (-02:00) and hence my conversion is all disturbed by one hour difference.
I even tried hardcoding it like below and the value dumped on production sometimes gives (-02:00) and other times the correct value which is (-03:00).
$date = Carbon::now(tz: 'America/Sao_paolo')->getOffsetString();
dd($date);
What is the solution for this?
in the AppServiceProvider.php you can add a little script for the whole Laravel app , please check
public function boot()
{
date_default_timezone_set('America/Sao_Paulo');
}
my issue is that I want to be able to get two time stamps and compare if the second (later taken) one is less than 59 minutes away from the first one.
Following this thread Compare two dates with JavaScript
the date object may do the job.
but first thing i am not happy with is that it takes the time from my system.
is it possible to get the time from some public server or something?
cause there always is a chance that the system clock gets manipulated within the time stamps, so that would be too unreliable.
some outside source would be great.
then i am not too sure how to get the difference between 2 times (using 2 date objects).
many issue that may pop up:
time being something like 3:59 and 6:12
so just comparing minutes would give the wrong idea.
so we consider hours too.
biut there the issue with the modulo 24.
day 3 23:59 and day 4 0:33 wouldnt be viewed proper either.
so including days too.
then the modulo 30 thing, even though that on top changes month for month.
so month and year to be included as well.
so we would need the whole date, everything from current year to second (because second would be nice too, for precision)
and comparing them would require tons of if clauses for year, month, etc.
do the date objects have some predfeined date comparision function that actually keeps all these things in mind (havent even mentioned leap years yet, have I)?
time would be very important cause exactly at the 59 minutes mark (+-max 5 seconds wouldnt matter but getting rmeitely close to 60 is forbidden)
a certain function would have to be used that without fail closes a website.
script opens website at mark 0 min, does some stuff rinse and repeat style and closes page at 59 min mark.
checking the time like every few seconds would be smart.
Any good ideas how to implement such a time comparision that doesnt take too more computer power yet is efficient as in new month starting and stuff doesnt mess it up?
You can compare the two Date times, but when creating a date time there is a parameter of DateTime(value) which you can use.
You can use this API to get the current UTC time which returns a example JSON array like this:
{
"$id":"1",
"currentDateTime":"2019-11-09T21:12Z",
"utcOffset":"00:00:00",
"isDayLightSavingsTime":false,
"dayOfTheWeek":"Saturday",
"timeZoneName":"UTC",
"currentFileTime":132178075626292927,
"ordinalDate":"2019-313",
"serviceResponse":null
}
So you can use either the currentFileTime or the currentDateTime return from that API to construct your date object.
Example:
const date1 = new Date('2019-11-09T21:12Z') // time when I started writing this answer
const date2 = new Date('2019-11-09T21:16Z') // time when I finished writing this answer
const diff = new Date(date2-date1)
console.log(diff.toTimeString()) // time it took me to write this
Please keep in mind that due to network speeds, the time API will be a little bit off (by a few milliseconds)
Context
I have multiple servers listening to a specific collection (/items). Each of them use NTS for time calibration and the ".info/serverTimeOffset" to measure the expected time difference with Firebase. It is consistently around 20ms.
I have many clients pushing items to the collection with the specific field:
{
...
created: Firebase.database.ServerValue.TIMESTAMP
}
What is expected:
When the server receives the item from Firebase and subtracts the item.created with the Firebase expected time (Date.now() + offset), this value should be positive and probably around 10ms (time for the item to be sent from Firebase to the server).
What is happening:
When the server receives the items, the item.created field is superior to the Firebase expected time. Like it was created in the future. Usually the difference is around -5ms
Question:
What is the Firebase.database.ServerValue.TIMESTAMP set to ? and how is it related to the ".info/serverTimeOffset" ?
The 27th September 2016 at 1am UTC, that difference jumped from -5ms to around -5000ms like a kind of re-calibration happened (it lasted until I reset the .info/serverTimeOffset) Did someone experienced something similar?
My code fetches calendar events using service.events().list() with the following parameters:
timeMax: 2015-11-13T04:12:44.263000Z
timeMin: 2014-05-17T04:12:44.263000Z
updatedMin: 2014-11-12T14:56:20.395000Z # = yesterday
I know there's a limit on the updatedMin param that prevents it to be too far in the past, but lately I get the following error even when updatedMin is yesterday:
The requested minimum modification time lies too far in the past.
Everywhere this error is mentioned, they are talking about a limit that is approx. 20 days in the past, certainly not one day.
Any ideas what is causing this error?
#Tzach, I tried the above query in API explorer with the same values and it returned the results without any error unless its greater than 20days. As Luc said, better to switch to syncTokens which saves the bandwidth.