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?
Related
I'm trying to visualize my weather data using grafana. I've already made the prometheus part and now I face an issue that hunts me for quite a while.
I created an counter that adds temperature indoor every five minutes.
var tempIn = prometheus.NewCounter(prometheus.CounterOpts{
Name: "tempin",
Help: "Temperature indoor",
})
for {
tempIn.Add(station.Body.Devices[0].DashboardData.Temperature)
time.Sleep(time.Second*300)
}
How can I now visualize this data that it shows current temperature and stores it for unlimited time so I can look at it even 1 year later like an normal graph?
tempin{instance="localhost:9999"} will only display added up temperature so its useless for me. I need the current temperature not the added up one. I also tried rate(tempin{instance="localhost:9999"}[5m])
How to solve this issue?
Although a counter is not the best solution for this use case, you can use the operator increase.
Increase(tempin{instance="localhost:9999"}[5m])
This will tell you how much the counter increased in the last five minutes
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)
In consul's documentation, it states:
This endpoint returns the most recent events known by the agent.
What does it mean exactly by most recent? Most 100 recent events? 1000? Events fired in the last 7 days?
Is there a way for me to configure this?
My concern is this event list could grow infinitely large if older events are not removed within a reasonable amount of time (which can vary across different applications).
So after some digging into the source code of consul. I found out it is max 256
https://github.com/hashicorp/consul/blob/94835a2715892f48ffa9f81a9a32808d544b1ca5/agent/agent.go#L221
eventBuf: make([]*UserEvent, 256),
On below you can see the rotation
https://github.com/hashicorp/consul/blob/94835a2715892f48ffa9f81a9a32808d544b1ca5/agent/user_event.go#L229
a.eventBuf[idx] = msg
a.eventIndex = (idx + 1) % len(a.eventBuf)
Below code shows that the data is pulled from the same buffer only
https://github.com/hashicorp/consul/blob/94835a2715892f48ffa9f81a9a32808d544b1ca5/agent/user_event.go#L235
func (a *Agent) UserEvents() []*UserEvent {
So you can safely assume, this will be max 256
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.
I have a program that sends calendar appointments out to users. However these users are in many different time zones. When I create the .ics file, I set the time zone to the local time zone, because they are scheduled here. They then get sent out to the users, who are scattered across many time zones.
Will outlook handle this correctly? As in: if I schedule a person for an 8am meeting and I am in Philadelphia, it should come up as 8am meeting for them in any other time zone.
I know that Outlook works with time zones to an extent, but I couldn't find any good documentation on it.
EDIT:
I really should have asked something more along the lines of how do you format it to handle this correctly, here is the format I am currently using. But I have little experience with this so I might be doing it wrong:
String[] iCalArr = { "BEGIN:VCALENDAR",
"PRODID:-//foobar//morefoobar//EN",
"VERSION:2.0",
"CALSCALE:GREGORIAN",
"METHOD:REQUEST",
"BEGIN:VTIMEZONE",
"TZID:America/New_York",
"X-LIC-LOCATION:America/New_York",
"BEGIN:DAYLIGHT",
"TZOFFSETFROM:-0500",
"TZOFFSETTO:-0400",
"TZNAME:EDT",
"DTSTART:19700308T020000",
"RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU",
"END:DAYLIGHT",
"BEGIN:STANDARD",
"TZOFFSETFROM:-0400",
"TZOFFSETTO:-0500",
"TZNAME:EST",
"DTSTART:19701101T020000",
"RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU",
"END:STANDARD",
"END:VTIMEZONE",
"BEGIN:VEVENT",
"DTSTART;TZID=America/New_York:" + strBeginDate,
"DTEND;TZID=America/New_York:" + strEndDate,
"DTSTAMP:" + strNow,
"UID:DT 2012 Training - " + System.Guid.NewGuid().ToString(),
"RECURRENCE-ID;TZID=America/New_York:20110207T103000",
"CREATED:" + strNow,
"DESCRIPTION;ENCODING=QUOTED-PRINTABLE:foobar",
"LAST-MODIFIED:" + strNow,
"LOCATION:" + location,
"SEQUENCE:1",
"STATUS:TENTATIVE",
"SUMMARY:foobar",
"TRANSP:OPAQUE",
"END:VEVENT", "END:VCALENDAR" };
Outlook should handle that just fine, assuming your particular application writes out proper timezone information. Or perhpaps works in UTC and marks everything with the Z zone.
I'm confused by your remark that "testing is not an option". I can imagine the unidentified "program" being unable to write out test data, but your question indicates you worry about Outlook. Surely you can handedit some ICS files with different timezones and feed them to Outlook? This should clearly indicate that Outlook knows how to deal with them.
yes Outlook handles time zones, this article from the KB actually indicates a limitation which is that Outlook needs to be updated everytime a timezone (DST, ...) is changed:
http://support.microsoft.com/kb/931667