When working with the chat API, requesting chats for before: or after: require providing timestamps. However, there is no guarantee that whatever machine we are using to make requests has a date anywhere near the date the server uses, so it is difficult to provide valid dates without simply relying on both machines having functioning NTP (think chat API requests from a raspberry pi without a real time clock; it boots up and thinks it's 1970 for some time before it figures out the real date). If every chat API request -- even polls that come up empty -- included timestamp from the server, then we could use our initial account info call to figure out a reasonably-accurate "now" time on the server, and work off of that, and update that on every poll. My thought would basically be adding server_time:1234567.890 as a top-level field, alongside ok and the other call-specific data (my hope is that adding data won't break any existing callers) This timestamp could be the time our request was received, or the time it was processed. If it is a little off by the time it gets sent that is fine (we have to expect a network hop after it anyway, after all), what is important is that it is a *reasonably* current timestamp as measured on the server's clock, which we can then use as a reference point. The clock on our machine is not comparable to the clock on the server, but even a kinda-wrong date from the server is comparable to other dates on the server.