Documentation for Incoming Message Timestamp states that incoming message is stamped with server time.
Unfortunately there is no TimeZone information tagged with the returned value and its difficult to do any sort of operation using the time. Like for example Sinch API replays back all the messages since last 30 days if the App was uninstalled and installed. Because of this reason the incoming message time stamp is very critical as we need to ignore an already replayed message.
Is there a way we can retrieve the TimeZone information of the server so that we can use time zone offset in all our time arithmetic?
We will update the documetation, its UTC time everywhere from us
Related
I am trying to retrieve messages from IBM mq with a specific time range for example messages that were put over the past 2 hours or from 0500 to 0600 or between dates or 2 days back. if possible please provide a sample java code. Thank you
What have you written so far? Or are you looking to pay a consultant to do it for you?
Basically, you have to browse with a lock, and check the message's timestamp to see if it is in the time range, if yes, perform a destructive MQGET otherwise browse the next message.
I'm facing an 403 error when using this endpoint: https://developers.google.com/android-publisher/api-ref/purchases/voidedpurchases/list
But the error only occurs when I pass the startTime/endTime param, without this parameter I can access this endpoint correctly.
I'd like to know if somebody else know witch permission is missing.
I already gave to my service account permission in google play developer console related with orders and purchases.
https://developers.google.com/android-publisher/api-ref/rest/v3/purchases.voidedpurchases/list
Is it possible you are making an error in how you’re specifying either of the parameters? What does your request look like?
startTime
string (int64 format)
The time, in milliseconds since the Epoch, of the oldest voided purchase that you want to see in the response. The value of this parameter cannot be older than 30 days and is ignored if a pagination token is set. Default value is current time minus 30 days. Note: This filter is applied on the time at which the record is seen as voided by our systems and not the actual voided time returned in the response.
endTime
string (int64 format)
The time, in milliseconds since the Epoch, of the newest voided purchase that you want to see in the response. The value of this parameter cannot be greater than the current time and is ignored if a pagination token is set. Default value is current time. Note: This filter is applied on the time at which the record is seen as voided by our systems and not the actual voided time returned in the response.
Perhaps you’re specifying a value which is out of the expected range?
At the bottom of the page there is a “Try this api” section so you can try out parameters in their form, so you can see if you’re making some kind of mistake..
I have a channel in slack, to which a CI tool sends notification. The CI tool sends notification for failure for every operation and there is no way to filter it out. But I know that important notifications come from 12 AM to 2 AM. Is there a way that I can apply a filter daily on that channel between two time intervals ?
Yes. you can call the API method conversations.history, which will return messages from a channel. By settings the parameters oldest and latest accordingly you will only get messages from a specified timeframe.
Note that those parameters are provided as absolute timestamps (e.g. 1234567890.123456), so you need to calculate them for the current day.
According to the Gmail API reference, Users.messages: list "[lists] the messages in the user's mailbox". In my observation, the messages are returned in descending order by data. Is this a correct assumption?
Basically I want to be able to process a user's inbox after a couple of days without reprocessing messages I have already processed. I would do that by stopping once I stumble upon an email I have seen before. Using the history doesn't work reliable, since it is documented that history might expire within a few hours, requiring a full new sync.
Yes, you are correct. Messages are returned in descending order, with the newest one first.
You could save the internalDate of the newest message and list new messages with that value in the query a few days later.
Example
internalDate = 1490213949000 // Wed Mar 22 2017 21:19:09 GMT+0100 (CET)
q=after:1490213949 // 'after' takes seconds since the epoch. internalDate/1000
I am writing a Message Handler for an ebXML message passing application. The message follow the Request-Response Pattern. The process is straightforward: The Sender sends a message, the Receiver receives the message and sends back a response. So far so good.
On receipt of a message, the Receiver has a set Time To Respond (TTR) to the message. This could be anywhere from seconds to hours/days.
My question is this: How should the Sender deal with the TTR? I need this to be an async process, as the TTR could be quite long (several days). How can I somehow count down the timer, but not tie up system resources for large periods of time. There could be large volumes of messages.
My initial idea is to have a "Waiting" Collection, to which the message Id is added, along with its TTR expiry time. I would then poll the collection on a regular basis. When the timer expires, the message Id would be moved to an "Expired" Collection and the message transaction would be terminated.
When the Sender receives a response, it can check the "Waiting" collection for its matching sent message, and confirm the response was received in time. The message would then be removed from the collection for the next stage of processing.
Does this sound like a robust solution. I am sure this is a solved problem, but there is precious little information about this type of algorithm. I plan to implement it in C#, but the implementation language is kind of irrelevant at this stage I think.
Thanks for your input
Depending on number of clients you can use persistent JMS queues. One queue per client ID. The message will stay in the queue until a client connects to it to retrieve it.
I'm not understanding the purpose of the TTR. Is it more of a client side measure to mean that if the response cannot be returned within certain time then just don't bother sending it? Or is it to be used on the server to schedule the work and do what's required now and push the requests with later response time to be done later?
It's a broad question...